Although understanding exception handling and being able to use the try...catch construct is good to know, it is more important to know when to use it.
The try...catch construct should be used to catch exceptional errors and iterating over an array should not cause exception because we always know the array or list size.
So by all means learn it, but don’t use it in a GoL project.
Game of Life is a fun interesting project which I first implemented several decades ago when I was fairly new to programming. It wasn’t very efficient but as my programming skills improved so has my algorithm to the point I have no need to perform any arrays bounds checking. It uses just two 2D arrays and a list. If you are familiar with bit operations it can be done with just one 2D array and a list. (you can see the algorithm in action here on my website)
I know this discussion is about try...catch so I won’t explain the algorithm here unless you want me to,
This cannot be overstated! Never* use exceptions and try/catch for program logic. Using try when the exception doesn’t happen is very efficient - triggering the catch, and particularly the actual creation of the exception, is really inefficient.
OK, as with everything, almost never - there are cases - this definitely isn’t one of them!
Especially when your program is still in the making and not yet finished, try-catch can obscure the true cause of an error. Very dangerous.
As far as I know it’s there to check when something breaks during you run the Sketch, e.g. a file you load is not there or an Internet resource. It’s a trick for the unforeseeable, not for the foreseeable.
Er, no, definitely not what I meant. Never use try in place of if. The core JDK libraries are a bit lacking here in the lack of a tryParse function, but just because they’re lacking doesn’t make it a good idea. And with Processing, use the internal parsing functions that at least handle the catch / hide the exception for you. Still slow though! There are (Java) libraries that can do this more efficiently.
OT - When I said “never” use for logic, I had in mind a couple of ways libraries I know have used exceptions to support things that cannot otherwise be easily expressed. They will generally use their own exception classes too, to remove some of the things that make exception creation non-performant.