We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProgramming Questions & HelpOther Libraries › Shouldn't Client() throw an Exception
Page Index Toggle Pages: 1
Shouldn't Client() throw an Exception? (Read 536 times)
Shouldn't Client() throw an Exception?
Sep 15th, 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.
Re: Shouldn't Client() throw an Exception?
Reply #1 - Sep 29th, 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...
Re: Shouldn't Client() throw an Exception?
Reply #2 - Sep 29th, 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.
Re: Shouldn't Client() throw an Exception?
Reply #3 - Sep 29th, 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 ?
Re: Shouldn't Client() throw an Exception?
Reply #4 - Sep 30th, 2008, 1:42am
 
dB wrote on Sep 29th, 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.
Re: Shouldn't Client() throw an Exception?
Reply #5 - Sep 30th, 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.
Page Index Toggle Pages: 1