Xojo supports the use of exceptions and the error handling machnisms that makes possible.
in order to use exceptions effectively you need to use a language feature called a Try block. It has several parts to it. First there is the initial TRY statement which opens a new scope level AND delimits where the TRY block starts. Its entirely possible to simply have code like
TRY // some code enclosed by the block END TRY
You are not forced to have a CATCH statement in a try block. This style can be useful if, for instance, in the try portion you assign a value to a variable when there is no exception raised and then check that variable after the block and behave accordingly. Perhaps something like
dim f as Folderitem TRY f = SpecialFolder.ApplicationData.Child("my.app.bundleID") END TRY if f is nil then f.CreateAsFolder end if
But not that this code _could_ have an issue of for some reason SpecialFolder.ApplicationData is nil. We didnt check that and should before just blindly using it. There are other ways to accomplish much the same task by dealing with whatever exceptions are raised. For instance you might rewrite the above code to
dim f as Folderitem TRY f = SpecialFolder.ApplicationData f = f.Child("my.app.bundleID") CATCH nilError as NILObjectException // hmmm this means SpecialFolder.ApplicationData is nil ? // we might show an error dialog to the user or something to // let them know that the folder we were trying to create cant be // created in the SpecialFolder.ApplicationData location // and we might return here rather than try to carry on END TRY if f is nil then f.CreateAsFolder end if
This style at least makes it so we have checked whether or not SpecialFolder.ApplicationData was nil – its unusual that it might be but can happen.
You can have as many CATCH statements as you want and they can be written in many different styles. Personally I always use the form
Catch ErrorParameter As ErrorType
with a name for the error parameter; which actually ends up being a local variable in the CATCH code you write, and a specific type. In my code you might see
TRY CATCH noExc as NilObjectException // code to deal with the Nil Object Exception CATCH ioExc as IOEXception // code to deal with the IO Exception END TRY
and specific code where noted by the comments to deal with the situation. I do not recommends using a single catch with a long list of select statements using introspection etc to try and handle the various exceptions. The only time I might recommend that is when its the App.Unhandled exception event and you are trying to create a report that a user can send you. Even there you have to be careful of which exceptions you catch because a normally Quit application uses an exception to Quit normally.
The last part of a TRY CATCH block is the FINALLY block. This is code that runs after all the code in any TRY or CATCH sections executes. Some times there is code that you want to execute as part of clean up that needs to release memory, mutexes, semaphores etc.
However, some assume that it will ALWAYS execute regardless of what code you have in the TRY and CATCH portions. In some languages the code in the FINALLY block is ALWAYS executed. This is NOT the case in Xojo and, if you’re not careful, it CAN easily be skipped.
For instance, if you use RETURN as the last line of the TRY or a CATCH block that is executed the FINALLY block WILL be skipped.
Try Raise New NilObjectException Catch Return Finally Break End Try
If you execute this code you will see that the BREAK in the finally block is NOT executed. And if you changed this to
Try Return Catch Finally Break End Try
Again you will see the break in the finally clause is not executed. So be careful about the use of return in a TRY CATCH block IF you expect the FINALLY clause to always be executed.