Processing 1.0 - Processing Discourse - Shouldn't Client() throw an Exception?

dB

Shouldn't Client() throw an Exception?
Sep 15^th, 2008, 8:14pm

This is a question regarding the Net library:

I've just noticed that the Client(PApplet, host, port) constructor doesn't throw any exceptions? Is that intentional?

Unless I'm missing something, it makes it impossible to handle errors when connecting to a server using a try/catch statement..

The other constructor Client(PApplet, java.net.Socket) does throw an exception, but requires handling the Socket object yourself.

Any thoughts / solutions?

d.

dafdaf YaBB Newbies Offline Posts: 9	Re: Shouldn't Client() throw an Exception? Reply #1 - Sep 29^th, 2008, 11:17pm I'm having the same problems trying to do an installation with four computers over wlan, I've got big troubles handling network errors. Could you solve your problem? If someone has a hint I'd really appreciate it...

dB

Re: Shouldn't Client() throw an Exception?
Reply #2 - Sep 29^th, 2008, 11:30pm

After some more playing around, my understanding now is that Client() sidesteps the complexity of exceptions altogether, at the cost of flexibility and reliability. That makes sense.

From where I'm standing, if you're doing anything more complicated than just hooking up a single client to a server (without ever disconnecting), I think you'll probably want to write your own Java classes to handle the client/server stuff.

dafdaf

Re: Shouldn't Client() throw an Exception?
Reply #3 - Sep 29^th, 2008, 11:36pm

Thanks for your quick answer !

Actually that is what I cannot do (not enough Java knowledge and not enough time).
Maybe someone can point me to another workaround/solution to this problem.

To be a little bit more specific: The network stuff I do is very basic. Connecting to two servers and receiving streams of data (to visualize). The problems start already while connecting. - If the server is not available at the moment, the client will die. This I can catch by relaunching the processing sketch every couple of sec. (Oh shit that's reaaaaly dirty.) The bigger problem is a disruption of the network traffic while the sketch is running.
Currently I'm trying with exceptions and disconnectEvent - so far without success.

Btw. how complicated would it be to bypass Processing's net.client and use native Java for that task ? Any idea ?

fry

Re: Shouldn't Client() throw an Exception?
Reply #4 - Sep 30^th, 2008, 1:42am

dB wrote on Sep 29^th, 2008, 11:30pm:

After some more playing around, my understanding now is that Client() sidesteps the complexity of exceptions altogether, at the cost of flexibility and reliability. That makes sense.

From where I'm standing, if you're doing anything more complicated than just hooking up a single client to a server (without ever disconnecting), I think you'll probably want to write your own Java classes to handle the client/server stuff.

That's correct, we hide exceptions in nearly all of the API to make this tradeoff, generally choosing another method for handling their error messages. For instance, loadImage() returns null (and prints an error message to the console) when image loading fails (rather than producing
all manner of exceptions).

But if you need more control, the Client class is about 500 lines of code, and included with the Processing download so that you can modify it for your own use. It's very simple.

And for the original poster, use client.active() to determine whether the client has failed/disconnected/whatever. No need to restart the sketch completely, or rewrite everything in Java.

dB YaBB Newbies Offline Posts: 23 Canada	Re: Shouldn't Client() throw an Exception? Reply #5 - Sep 30^th, 2008, 2:05am Thanks for the reply. I hadn't looked closely enough at first. I didn't realize that when a new Client() is created and fails, the exception is merely printed out, yet it returns a valid object and doesn't interrupt the code. Best, d.