URLConnection.Error

Hey all,

I’m using a URLConnection to Asynchronously grab some data from a device. I’m issuing multiple calls and I’m getting a a Runtime exception raised where the error messages is “A request is already in progress.” Fine. I requested data when I’m waiting on data to come back. But this is exception is not being raised by the URLConnection’s error event. It’s going directly to the UnhandledException event of my app.

Shouldn’t this be handled by the Error event of the URLConnection? I’m happy to file a bug report but I don’t know how I can provide an example project that would reproduce this…

I just discovered the same issue - if the site is offline and you issue a urlConnection.send then you get no indication that the first message didn’t go through or that connection not made. I suppose that is the asychronous world we are in.

There is a very long timeout - that gives you an exception error that can be trapped - but it is probably too long for most purposes. I think the solution is to implement your own timer to look for a returned event.

If you send another request - you get the above mentioned “A request is already in progress” with error number 0 (which I thought usually meant OK) - so you have to trap for that as well.

Sometimes simplifying things just makes things more complicated.

I’m a little late to the party on this one but hopefully this will help someone out…

No. I don’t believe that it should. URLConnection.Error is “called when an HTTP error occurs.” and the ‘request is already in progress’ error is not an HTTP error sent back from the server, rather a runtime exception caused by the fact that the method is currently in use.

I’ve found that the most common cause of “A request is already in progress.” is because I’ve called the URLConnection.Send() method twice by accident. For example, putting it into the menu handler that opens a window and then also in the Activate event of the window itself.

Has anyone found a way to use URLConnection without all the exceptions? I’ve tried migrating a couple of uses of HTTPSocket to URL but since they ping a sever regularly, any network issues present as an exception rather than just a failure which throws the debugger into a break repeatedly. I’ve always seen exceptions as a programming/stack error handling rather than for network issues.

Exceptions are just an indication that something exceptional or unexpected happened. The right way is to wrap your code in try-catch blocks.

If you are absolutely sure that you’ve trapped all of the possible exceptions, you can always add

#pragma BreakOnExceptions False

Before the code and

#pragma BreakOnExceptions True

Afterwards

Thanks Greg. I’d not used those pragma statements before, very handy.

Interestingly they don’t seem to prevent a break when used in a method called by a thread. I’ve put them around 2x URLConnection calls, one in a timer and one that gets called by a thread. The timer one is correctly ignored, the thread called one still breaks. This is 2019.3, I’ll try in 2020 tomorrow.

Why the change from an error event based system in SocketCore to this new exception heavy way?

I’ll try a subclass that calls an event on exception, should work?

Xojo’s moving toward an exception based error system for just about everything. I think the reason is that the exception makes you do something about the error. Error codes can be ignored. Exceptions can’t or they crash your program.

Now do I think that it’s “fair” to crash an app because of a call to a URLConnection? No, I really don’t. But I should also be aware that I need to handle possible error conditions. So having the possibility of an exception that could crash my program forces me to handle the error condition.

That seems to be how I gather it. Still, it’s nice to be able to look at en error code property and see what is going on.

Yes. I like URLConnection, but I feel because of its asynchronous nature it is not meant to be used as a socket control in most cases.
I built a connection factory rather that creates URLConnections, manages their events and keeps them alive while in use. That‘s somewhat missing for a comfortable usage.
Disabling the exception Break by pragmas adds a bit of typing, admittedly. Besides that I like the exception approach because of the cleaner code structure.
And yes, the call from a thread is possibly the reason for the pragma not working in your case.

Eric,

URLConnection does have synchronous methods. I don’t think they worked properly at first, but I believe they do now. I was originally using synchronous methods in a standard HTTPSocket but that was no longer compatible with HTTP 1.1 and the latest security. So I then looked into the Xojo.Net.HTTPSocket which is missing quite a bit and which is asynchronous only. Then they came out with URLConnection. So I migrated everything to that but early on there was an issue with synchronous connections. So I adapted and migrated to an asynchronous architecture. I’m actually happier with that as my code is more responsive rather than it sitting and waiting with a spinning beach ball for the response to come back from the server.

The difficult part about an async socket is know if there is a call already in place. If you make an additional call while one is in process you’ll trigger an exception. A try/catch block resolves that nicely. It would be nice if there was a property that you could look at to see if the connection is active.

That is actually a really good idea, Ulrich. I like that!

Unless something has changed - which I don’t recall seeing anything in the release notes about this - URLConnection’s synchronous methods are a performance nightmare.

From the blog post:

The problem is URLConnection.SendSync still eats up a lot of cycles while working. I had a user with eight servers tell me it took about nine minutes for one of them to finish. All the threads were fighting for resources and making everything take far longer than it should. I suspect Xojo needs to make the method sleep longer, but that’s just a guess.

Despite its problems, URLConnection is still better than HTTPSecureSocket and Xojo.Net.HTTPSocket.

I would never use a synchronous call for anything but the simplest requests. The fact that someone with 8 servers was using synchronous sockets in threads tells me they were not coding properly! It’s fairly easy to create a handler for the finished result of the asynchronous calls. Performance is way mo betta!

1 Like

The key is each request was inside its own thread. That should work fine. The issue I believe is they aren’t yielding enough time. The blog post has all the details.

Ooops, Thom! It was you who wrote that code. :face_with_hand_over_mouth:

Did you mean me? Or do I ignore some Eric here inadvertently?
If so: Never mind, and thanks! As a hint: I built a URLConnection subclass too where I can add a tag, and which does time/speed measurements for me. The tag makes it much easier to respond to different replies you are expecting.

Ulrich - yes. Typo on my fat fingers. :slight_smile:

Heh, don’t worry.

1 Like

But if you are putting it in a thread, isn’t running asynchronously just as easy?

Not if I want the effect of synchronous code.

I don’t think so. A synchronous method is not meant to be used pseudo-asynchronously, especially because of the nature of Xojo’s threads. That’s why Christian created some MT methods for similar tasks – synchronous calls which you can use inside a Xojo thread because they are designed to yield.
A URLConnection.SendSynch is not designed to yield, even more if you read the notes on the possibility of GUI freezes.