Try/Catch UnsupportedFormatException Isn't Catching

We’re trying to upload either a jpg or png using a WebFileUploader something like this:

[code]For Each file As WebUploadedFile In Files
Try
dim thePicture as Picture
thePicture = Picture.FromData( file.data )
PhotoImageWell.Picture = thePicture

Catch e As UnsupportedFormatException
Continue // Skip this file
End Try
Next[/code]

We’re upload non valid photos to test the error handling, but when debugging the debugger pops up to let us know we have an UnsupportedFormatException. Shouldn’t the catch intercept that and not cause the debugger to engage?

Uncheck “Break on Exceptions” in Project.

Thank you so much Michel! That was perfect.

I tried commenting out the Try / Catch and it did break since the Try / Catch wasn’t there as expected…

No. The debugger comes up for all exceptions if “Break on Exceptions” is checked. From the Using the Debugger topic:

Something like

[code]
For Each file As WebUploadedFile In Files
#pragma BreakOnExceptions Off // turn off the debugger breaking on exceptions
Try
dim thePicture as Picture
thePicture = Picture.FromData( file.data )
PhotoImageWell.Picture = thePicture

Catch e As UnsupportedFormatException
Continue // Skip this file
End Try
#pragma BreakOnExceptions On // turn it back on

Next[/code]

When BreakOnExceptions is turned on, the debugger will break as soon as the exception is raised, before any exception handling is done, including code inside a Catch clause. If you resume execution the Catch clause will run as expected.

I find this sort of coding so totally clunky. Isn’t there a better way to do this? Especially with the new framework where we are supposed to deal more often with exceptions.

You can also do #Pragma BreakOnExceptions False at the top of a method to turn of exception breaking just inside that one method.

@Jordan: and that fubars debugging even worse than just adding #Pragma BreakOnExceptions False where you need it.

Exceptions are appropriately named : they are supposed not to be the rule. I remember a thread where someone was actively relying on exceptions in his code. THAT is clunky. And probably way slower than testing conditions.

That said, try Catch has the advantage of offering better encapsulation than App.UnhandledExceptions, which is great for third party classes. I use it in RubberViews, for instance, so it remains self contained.

I usually develop my apps without exception handling, so I have a chance to prevent them by testing conditions such as nil objects. Then when the program runs, I add App.UnhandledExceptions to make sure there will be no crash, and add a few try catch where absolutely required.

However, there is no simple rule. I guess it all depends on the kind of program and personal programming style.

There are lots of philosophical arguments about how to handle errors.
Some like error codes - but they’re easy to ignore, or worse misinterpret.
And they have very little “depth” to them.
Say a BSD layer api causes an error that ripples back up through CF objects to a Xojo error - right now you get one code and no eeper understanding of what the issue was.
Apples NSError handles that but again you could just ignore them

And return codes cost you time & coding at every point you have to check them
Even if nothing goes wrong you have to check

Exception allow us to provide deeper information AND cost you nothing at runtime unless something goes wrong

They’re not perfect - granted.
But they’re better than a mish mash of inconsistent means to deal with error checking and error handling