I’d really like some help with error trapping in xojo as I am a bit of a xojo newbie and error trapping was relatively straightforward in Visual basic but seems to have defeated me in xojo.
What I’d like to do ultimately is trap runtime errors send the error message to an email then email myself with the info for updating purposes.
However before I do any of that I have been playing with errors in xojo. I started with division by 0 which is likely to be the most common error for my app I think. So I wrote a little app to force a div by 0 then finding a way to trap it. A textfield and OK button - the ok button takes the value of textfield converts it to a number then divides the number by 0 purposely. I cannot seem to trap this error and simply get (dependent on whether A(the numeric value of textfield) is integer, single double) odd values like -2147483648 (Integer) or -1.#ind (double or single) i.e xojo (or realbasic) does not fall over and create an trappable error as far as I can see for div by zero. Even when I try to “trap” -2147483648 I cannot. This leads me to think I am doing something fundamentally wrong and I cannot see what it is.
So best advice on trapping error please. I have tried “try” and “catch” but I am not getting anywhere and if I am unable to trap a simple error like div by zero then lord know how to trap other likely/foreseeable but more complex errors.
While testing errortrapping myself I came across that devision by zero didn’t raise an exception in Xojo. How strange, since my mathematics teacher told me 35 years ago that this is just the example of infinity that cannot be expressed as a numeric value.
It depends on what you’re doing. Personally I like to use Try-Catch because the condition is right there where the exception occurs. When there are Exception blocks at the bottom of a section of code, I often miss it when reading the code later
I suspect that Xojo did not feel it was necessary to deal with this as an exception since div by zero is handled by IEEE 754 (NaN, INF, etc) This is the same as in many modern languages.
Yes Greg I do agree that using Try … Catch, rather then Exception err, is good for the readability of the code. But what is runtime (compiled) the most efficient way ?
That is an interesting question. I guess to simulate a ‘Resume Next’ you just need to have smaller try…catch blocks and allow the execution path to continue. For a ‘Resume previous’ you could duplicate your ‘previous’ code inside another try…catch nested in the catch section or you could use the much hated Goto statement to jump back to the code that caused the exception but without extra logic your code could just end up looping around.
put the try catch around the smallest logical unit of work that you care to deal with
some folks write large methods with one try catch around the whole thing & try to deal with every issue at the very end (ick)
in VB you might do something that caused an exception, catch it at the VERY end of the routine & then need to resume next
(this is completely made up - I haven’t written VB code in about 13 years
dim v as integer
v = 123/0
return v
exception
v = 0
resume next
in Xojo (if div by zero were an exception) you might do
dim v as integer
try
v = 123/0
catch exc as DivByZeroException
v = 0
end try
return v
So the statement is clear: “put the try catch around the smallest logical unit of work that you care to deal with” is the one and only good solution do to proper error handling. Thanks…
hi joost unfortunately not always works this solution about smallest try catch. I’ve a problem importing a text file with unallowed character encode in one specific field and i got exception also using a small try catch around that field
By default, the debugger always stops on exceptions, to give you the opportunity to review variables, etc. You may simply press Resume and execution will proceed through the try/catch, etc. The compiled app will not throw an exception. You can turn BreakOnExceptions off if you don’t want the debugger to pause.
