Try...Catch still shuts down the app

I am using an URLConnection to download a picture file depending on the value of a variable. The URLConnection may sometimes throw an exception because the internet is currently down or a timeout occurred. I want to catch that exception so the application must not shut down. I wrapped a try … catch around the URLConnection, but every exception still shuts the application down. Here is a snippet of my code:

   Select Case IconSize
   Case "L"
      IconFileDownloader.SendSync("GET", ...
   Case Else
      IconFileDownloader.SendSync("GET", ...
   End Select
 Catch DownloadErr As NetworkException
   Window1.AddToLog "NetworkException. Internet down?"
   Return Nil
 End Try

Still, when an exception occurs, a windows pops up, stating “an exception of class NetworkException was not handled.” for example with exception error 2 which seems to be a DNS error.

What I want is that the app simply ignores NetworkException errors (except logging them) and continues to run until the next time I try to download the same file.

What am I doing wrong with my try…catch?

So… SendSync returns a string, so the code above wouldn’t even compile if IconFileDownloader is a URLConnection. Could you correct your code or give a little more context?

1 Like

Is Window1 a valid object?
If not, a second exception will happen in the ‘catch’ part of this code

SendSync does not return a string, it downloads the file into a FolderItem. Here is the full call:
IconFileDownloader.SendSync(“GET”, “” + IconID + “@2x.png”, IconFile)

It all works 99% of the time. If it fails, it triggers the exception which I try to catch and handle.

1 Like

Yes, but only when you provide three parameters. You cut off your code. We can’t help you if you don’t show us the code.


Do you break on exceptions? It should show you exactly where the exception is being raised. I’ve had trouble catching exceptions in App.Open with no main event loop yet, but I was doing some really fringe stuff.

Sorry. I thought it would not matter.

Yes, I do break on exceptions but it doesn’t work. I am remote debugging a RasPi from a Mac. When the exception occurs, the app on the raspberry will show a window with the exception and that the application must shut down. The debugger on the Mac will recognize that there was some issue, but it won’t show where.
If I run a compiled version on RasPi, of cause it only shows the exception occurred.

Since you are writing to a file try to catch the IOException too.

If you can create a reproducible example project I’m sure Xojo would like to fix it.

I might suggest switching to an asynchronous socket using the events instead for more reliability, but I don’t have any ideas as to why this would magically work. It just might though.

So I added another catch clause to see if this triggers
Catch FileIOErr As IOException
Window1.AddToLog “IOException beim Icon download. Datei kann nicht geschrieben werden?”
Return Nil

But that would be a work-around to something that I think should work as it is. I just don’t understand why my try…catch does not catch the URLConnections exception(s) as they occur.

Well we don’t know how all the innards of the Xojo Framework operate, so I don’t have an explanation for why it’s acting this way. The best I can offer is to “file a ticket” since you have an expectation that it is not meeting.

I offer the workaround as a hope to keep your development rolling, not to detract from your issue. I do hope you get it resolved.

I would be curious to know (for science!) if the workaround helps.


I re-read your case. It seems you can’t catch the networkexception since the message is forwared to unhandledexception. So somehow this seems te be handled in another place by the xojo framework instead of pushing it.

File a bugreport.

Fow now i’d use the async version, implement the event and handle it trough the events.

you need this above try?

#Pragma BreakOnExceptions False

Try changing one of the exception blocks to RuntimeException and see if you’re getting something else.

Another way of “solving” this would be to handle the exception in the app.UnhandledException event.
But you wouldn’t still figure out why the current way doesn’t work.

to all … thank you very much for all your helpful advises. In the end I completely re-wrote to whole method from scratch - and it helped! The TRY…CATCH block now successfully catches the NetworkException when it occurs. I even included caching the picture files to a folder so I only fetch it in case it’s needed to. The app keeps on running - already stable for a few days now. (running on a raspberry pi 3 B+)

So - thanks again to all! Case closed. (still looking into the Break on exceptions issue I had, where remote debugging on a Pi will not show where in code the exception occurred)