{"id":590,"date":"2020-02-04T12:08:00","date_gmt":"2020-02-04T19:08:00","guid":{"rendered":"https:\/\/www.great-white-software.com\/blog\/?p=590"},"modified":"2020-01-24T09:10:34","modified_gmt":"2020-01-24T16:10:34","slug":"exercise-caution-with-catch-clauses","status":"publish","type":"post","link":"https:\/\/www.great-white-software.com\/blog\/2020\/02\/04\/exercise-caution-with-catch-clauses\/","title":{"rendered":"Exercise caution with catch clauses"},"content":{"rendered":"\n
Xojo now generally uses exceptions to handle errors.<\/p>\n\n\n\n
And with that comes some things you should know about how exceptions work that you need to be aware of before you cause yourself problems.<\/p>\n\n\n\n
First off, in my opinion, you should put your try catch blocks as close to the code that causes the error. While Xojo lets you use one EXCEPTION or CATCH block at the end of any method like the following<\/p>\n\n\n\n
\n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\/\/ do a bunch of code \n\n\nCatch foo As RuntimeException \/\/ or Exception foo as RuntimeException\nBreak<\/code><\/pre>\n\n\n\n
I would suggest you avoid this form. It’s not obvious unless your methods are VERY short and it on one screen of code. For instance, does the following method have a catch ? Without actually looking at the very end you cannot tell (In fact it does but that isnt clear)<\/p>\n\n\n\n<\/figure>\n\n\n\n
As well using a single consistent form is probably a better practice than sometimes using this form and sometimes using other forms. Even if the entire method is surrounded in a TRY CATCH block its more obvious. This is the exact same method with the addition of the TRY keyword at the very beginning and “END TRY” at the very end<\/p>\n\n\n\n<\/figure>\n\n\n\n
try\n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \/\/ do a bunch of code \n \n \nCatch foo As RuntimeException \n Break\nEnd Try<\/code><\/pre>\n\n\n\n
The other thing to be careful about is how you write your catch statements. The documentation shows a legal CATCH statement as<\/p>\n\n\n\n
Note that EVERYTHING except the CATCH keyword is optional. Again I would suggest you almost NEVER use just a CATCH by itself as you will catch every type of exception, perhaps even those you cannot actually handle. <\/p>\n\n\n\n
The other thing that is often confusing is if you write<\/p>\n\n\n\n
Catch someException<\/code><\/pre>\n\n\n\n
which is legal what you have in fact got is<\/p>\n\n\n\n
Catch someException as RuntimeException<\/code><\/pre>\n\n\n\n
and the local variable is name someException<\/em>. Save yourself the grief and ALWAYS use the fully spelled out form of CATCH like<\/p>\n\n\n\n
Catch <localVariableUsableInTheExceptionHandlingCode> as <ExceptionType><\/code><\/pre>\n\n\n\n
Using it this way insures you are never surprised at catching more than you were prepared to handle. Also note that the localVariableUsableInTheExceptionHandlingCode<\/em> is in fact defining a local variable that you can use in the body of this specific CATCH block. What that means is code like<\/p>\n\n\n\n
Catch iox as IOException\n system.debuglog iox.errormessage\n<\/code><\/pre>\n\n\n\n
is legal and, in this case, iox is usable within the rest of the code following that catch until you get to another catch, the finally block, or the end try. The following WOULD NOT be legal<\/p>\n\n\n\n
Catch iox as IOException\n system.debuglog iox.errormessage\nCatch oob as OutOfBoundsException\n system.debuglog iox.errormessage<\/code><\/pre>\n\n\n\n
iox would not be in scope<\/em> in the code following the catch of the out of bounds exception. Nor would oob be usable in the block handling the IOException.<\/p>\n\n\n\n
And this last example shows something you can legally do. You can have more than one catch statement. The only thing you need to be careful about here is not catching the most general types before the more specific ones. What do I mean by that ? <\/p>\n\n\n\n
Since all exceptions are descendants of RuntimeException they are more specific types of exceptions than RuntimeException is. If your code was like<\/p>\n\n\n\n
Try\n Raise New nilobjectexception\n \nCatch rte As RuntimeException\n Break\nCatch noe As NilObjectException\n Break\nEnd Try\n<\/code><\/pre>\n\n\n\n
you would find that any code following the catch of the NilObjectException would NOT get executed. Because NilObjectException is descended from RuntimeException the first catch block will handle EVERY exception. Changing this code to<\/p>\n\n\n\n
Try\n Raise New nilobjectexception\n \nCatch noe As NilObjectException\n Break\nCatch rte As RuntimeException\n Break\nEnd Try\n<\/code><\/pre>\n\n\n\n
will now execute the NilObjectException code since that matches the more specific type. Note this is not peculiar to try catch statements but a general thing to keep in mind when dealing with if then else, select case and other kinds of statements that use boolean values to determine if their code should execute.<\/p>\n\n\n\n
Now go catch stuff \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
Xojo now generally uses exceptions to handle errors. And with that comes some things you should know about how exceptions work that you need to be aware of before you cause yourself problems. First off, in my opinion, you should put your try catch blocks as close to the code that causes the error. While … <\/p>\n
![\"\"](\"https:\/\/i0.wp.com\/www.great-white-software.com\/blog\/wp-content\/uploads\/2020\/01\/Screen-Shot-2020-01-16-at-12.14.11-PM.png?resize=525%2C383&ssl=1\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/www.great-white-software.com\/blog\/wp-content\/uploads\/2020\/01\/Screen-Shot-2020-01-16-at-12.15.33-PM.png?resize=525%2C395&ssl=1\")
<\/figure>\n\n\n\n