Why is this Try/Catch Block Not Working?

[quote=161252:@Sam Rowlands]That maybe, but I would recommend that you never do this. It took me weeks to figure out that my thread wasn’t working correctly because of it.

There’s a small notification in the language reference.[/quote]

This is the first I’m hearing of this. Where is that notification and how does this structure interfere with threads?

I found this in the LR.

I never looked much further, once I’d found that

catch err as RuntimeException

was causing my thread to run on the main thread and I had updated the code, I didn’t dig too much deeper into it.

I now see that it can be easily resolved, by simply re-raising the exception.

Thread context switching is done by means of an exception. If you catch that exception, no context switch takes place and your thread is no longer threaded.

Thats what I discovered… the hard way!

I’ve found that, but only noticed it when I used that form of catch-all within the thread, not on the main thread.

And I can’t create an issue, so I just don’t know how. However, you could always use this:

try
// some code
catch err as EndException
  raise err
catch err as ThreadEndException
  raise err
catch err as RuntimeException
  // your real code
end

Interesting. I’m inclined to think that context switching shouldn’t be implemented that way, because it appears to be a misuse of the exception concept and introduces hard to find bugs.

It isn’t. Only Thread.Kill and Quit use exceptions.

It’s not

My suggestion above doesn’t work. Raising the exception at the first stage will just get it caught at the second stage.

Memory error. Please replace hardware.

I must have been thinking Kill/Quit. I apologize to the forum for disseminating faulty information.

[quote=161259:@Norman Palardy]try catch noe as NilObjectException // code catch oob as OutOfBoundsException // code end try [/quote]

I didn’t realize you could have multiple catch blocks… makes sense… just didn’t think of it.

In each of the catch blocks, set a variable ExceptionThrown = true
And then add a block afterward that does this:

if ExceptionThrown then ...put your code here... End If

http://documentation.xojo.com/index.php/Select_Case can use multiple values separated by commas.

So, if you want to do it your way, you can catch all exceptions, then use a Select Case statement to do the right thing:

  try 
    ...
  catch e
     select case e
          case isa NilObjectException, case isa OutOfboundsException
             // do something
          case isa ThreadEndExepction, QuitException
             raise e // we mustn't catch these
           else
              // blah blah blah
      end select

Perhaps internally Xojo could split up these Exceptions. RuntimeException, EndException, and ThreadEndException would all be based on some new _InternalException class. All other Exceptions would still be RuntimeExceptions.

If your code catches EndException or ThreadEndException, it would be unaffected. If it catches everything else through RuntimeException, it would not be wrong.

Only if you did something like what Michael outlined above, and you really needed to catch one of the “End” exceptions, would you be affected, but I’d bet that would be a very small percentage.

Kem, I like your idea, so long as one could still catch ThreadEndExceptions and EndExceptions if needed - but I agree the default should be that these 2 exceptions are hidden from a normal ‘catch’ command.

[quote=162002:@Kem Tekinay]Perhaps internally Xojo could split up these Exceptions. RuntimeException, EndException, and ThreadEndException would all be based on some new _InternalException class. All other Exceptions would still be RuntimeExceptions.

If your code catches EndException or ThreadEndException, it would be unaffected. If it catches everything else through RuntimeException, it would not be wrong.

Only if you did something like what Michael outlined above, and you really needed to catch one of the “End” exceptions, would you be affected, but I’d bet that would be a very small percentage.[/quote]
Not without breaking existing user code which relies on the hierarchy of those two being subclasses of RuntimeException.

True, but Xojo changes break exiting code with some regularity, and this is one of those newbie “I’ll do it in a thread!” issues that has caught a lot of folks by surprise.

I would bet that of the developers using Xojo, perhaps 10% use threads at all, and of those, perhaps only 1% actually intentionally catch those two exceptions. (I know I don’t: the only reason I know about these two is that I had to write code to NOT catch them).

Let’s put it this way. We try really hard not to break user code, especially at the language level. This is one of the reasons for the new framework, so we can clean up mistakes of the past.

The vast majority of code should work without changes - and where it cant we don’t have much choice.
Threads were a good example of that - the UI toolkits forced us to make that an error since they themselves are not thread safe.

But most code should just work and my personal experience is that it does.
I’ve got projects that I’ve literally not touched in 6+ years that all open & run once I accept the control deprecation updates.
Beyond that no other changes have broken these projects.