Try Catch block query

Haven’t used Try…Catch blocks before but am using them in my first Web project.

When I run the code, it stops executing when it reaches the Try statement and I have to step through the code. Is that what is supposed to happen?

1 Like

I’m sorry, I think I must have clicked on the side accidentally and inserted a break arrow, which is what is stopping the execution. Sorry for the post.

Can you show us the block you have. It should look like this:

Try
   // Some operation
Catch oError as SomeExceptionClass
   // Do some recovery
End Try

Exceptions that occur in the lines between Try and Catch will trigger that code in the catch section. If they are of the correct type. You can have multiple catch sections with different exception classes, if required.

If you have “Break on exceptions” turned on in the project menu it will stop on the line that triggers the exception.

that is the stupid settings ever because it will show you all error handlings we made or nothing.

we have
https://documentation.xojo.com/api/language/pragma_directives.html#pragma-directives
#Pragma BreakOnExceptions True
#Pragma BreakOnExceptions False

No. But if you have a Try…Catch Section and a exception occurs within this section, the DEBUGGER will stop at the exception and then goto the fitting Catch x As … Block.

@MarkusR I find it very helpful. If you get an exception in your code but don’t know were and why it is happening you don’t really want to strip out every bit of exception handling from the entire application to track it down. Including “App.UnhadndledException”.

I would far rather turn on “Break on exceptions” and be shown the exact line that needs to be fixed.

Not in every case. I would still expect the debugger to stop on exceptions and show me how i handle them.

However, the pragmas allow us to change this default behavior (which I also want). :slight_smile:

1 Like

the issue is you will have sub sub sub methods and any of them already have an working try catch.
as example if you will cast a text input into currency.
and abc input will be 0.0 and textfield will be updated with 0.0
no need for a break there.
this BreakOnExceptions pragma is great.

I’m perfectly happy with the BreakOnExceptions pragma, however, The menu item is also super useful.

1 Like

i never have the need to put the menu Break on exceptions off.
exception can also occur outside/without a try catch where no error handling is so it must be always visible
at development and testing.
i believe Break on exceptions off is like on error resume next.

No, on error resume next simply ignores errors. Break on exception off simply allows the exception to occur, which in the absence of everything else would trigger an application UnhandledException event, if ignored will crash the application.

Well then, when you’re testing and are looking for an exception somewhere else, don’t enter abc into that TextField. Then you get the exception where it happens, as @Ian_Kennedy says.

i tested it if break on exection is off in menu you will get a messagebox from xojo and you not know the method/row where it happens.
at development i will see the break and line. thats why i mean this menu option makes no sense.
ms vb6 ide had a correct way for debugging.

just tested this in a button click

Var s As String = "abc"
Var ret As Integer = Currency.FromString(s)
System.DebugLog ret.ToString

I’m really sorry. I answered my own problem shortly after I posted the question and you have obviously missed my second post explaining this. I realised that I had accidentally clicked on the side of the page by the Try statement and Xojo had inserted a break at that point. I have always used the break statement and hadn’t realised that it was possible to break the execution in that way.

Thank you for all the suggestions and I apologise for taking up your time. I see there is a Solution flag at the bottom of the post window so I had better click on that now.

2 Likes

Add an UnhandledException event to your app class. Every application should have one if they don’t wan’t the app to crash when something unexpected goes wrong. If you have one of those then you will not get that dialog box from Xojo.

In my UnhandledException event handler I dump the application stack and also any debug info that is in my debug stack. I’m chasing an occasional Nil exception at the moment and I know which in method it’s happening thanks to the app stack and am using my debug stack to narrow it down.

Facilities like these need to be built into your app from the beginning otherwise when it happens you’re just wringing your hands and saying “Oh dear”.

I agree, it is one of the first things I add.