?

Log in

No account? Create an account
Help me I am in try / catch hell. - Adventures in Engineering — LiveJournal
The wanderings of a modern ronin.

Ben Cantrick
  Date: 2006-10-06 07:23
  Subject:   Help me I am in try / catch hell.
Public
  Mood:kkilllll meeee...
  Music:MC Plus+ - Computer Science 4 Life

Oh sure, I thought it would be a good idea to use Java to do some port forwarding code we need to extract a video stream off a webserver that's behind a NAT. "It'll be much faster than doing it in C" I said to myself, "and porting should be a snap!" I should have known better.

Let me put it this way: I think I've pretty much had to wrap every single @#$% call to read(), write() and Socket(...) with a try/catch block - some of them with multiple catches. Even socket.setSoTimeout() requires a try/catch block, for fuck's sake! I never had to check the return value from ioctl() in C.

Another thing that annoys me is that byte[]s are the best data structure for low level socket work, but there doesn't seem to be a way to "reset" one to zero length. I don't want to be new'ing 1k arrays constantly, but I have yet to find a good way to express "this array's contents have been transmistted, so feel free to over-write it." I ended up having to declare and maintain a separate int just to hold the number of bytes in the byte[]. Cuz, you know, letting me do byte[].length = 0 or byte[].empty() would have just been way too easy. Rargh!! Stuff like this makes MFC's CString class look well-designed in comparison! And don't get me started on the atrocious travesties that every Java sockets tutorial I've come across has been. I don't think the people who wrote most of those even tried to compile their own code, much less test what happens when a connection actually hangs up...


Well, jigenm4c just gave me some good tips, so maybe select() and http://www.javaalmanac.com will save my bacon. All suggestions are appreciated at this point...
Post A Comment | 9 Comments | | Link






Trevor Stone: java logo
  User: flwyd
  Date: 2006-10-06 19:21 (UTC)
  Subject:   (no subject)
Keyword:java logo
Arrays are intended to have fixed length for a variety of reasons, one being that the JVM knows how much memory to collect when it's done. If you're using a byte array for a 1K buffer you're probably best to create a wrapper object that has an int for the lenght that's been used. You can set that to 0 and then overwrite data. You can also use Arrays.fill if you want to set the bytes to all be 0 first for any reason. (System.arrayCopy from a static 0ed array might even be more efficient). A lot of the Java methods which take an array also allow start/end indecies, but if the code you're calling takes just a byte[] and wants to work on its whole length, there's not much to do but new.

I agree that checked exceptions are pretty annoying. Is there a reason you can't declare your methods throw IOException?

Writing text to a file is friendlier in Java than C. But I'm willing to believe that C makes it easier to throw chunks of raw data around.
Reply | Thread | Link



Ben Cantrick
  User: mackys
  Date: 2006-10-07 03:29 (UTC)
  Subject:   (no subject)
I'm stuck using the try/catch stuff because it's the only way I can reliably detect things like disconnection at odd times, and so on.

Now I'm having an even weirder problem. My code is claiming to read() a full 1024 bytes from a connection when only one character is sent...
Reply | Parent | Thread | Link



(no subject) - (Anonymous)
Ben Cantrick
  User: mackys
  Date: 2006-10-08 04:58 (UTC)
  Subject:   (no subject)
Java is much more efficient, the more you leverage it. Going all the way down to read() anyways, you more or less have tossed out any advantage you would get in Java versus C/C++.

If you know of a wrapper class to connect two incoming or two outgoing TCP/IP connections together bidirectionally, I'm all ears...
Reply | Parent | Thread | Link



Ben Cantrick
  User: mackys
  Date: 2006-10-08 05:02 (UTC)
  Subject:   (no subject)
Catch only exists for the circumstance that the (failed connection, file, poll, timeout, whatever) is recoverable. If it's not recoverable (and a connection failing isn't) propagate it back up the stack.

Au contraire, I *must* recover from dropped connections. That is part of the purpose of this code - to allow the webserver behind the NAT to go disconnected at times but re-establish the connection when it comes back online. Hence I am stuck using catch() blocks.
Reply | Parent | Thread | Link



Alex Belits: iskra
  User: abelits
  Date: 2006-10-07 12:09 (UTC)
  Subject:   (no subject)
Keyword:iskra
I still didn't get the reason why you didn't write it in C in the first place.
Reply | Thread | Link



Ben Cantrick
  User: mackys
  Date: 2006-10-07 22:46 (UTC)
  Subject:   (no subject)
I thought it would be faster to do it in Java.

Please kill me!
Reply | Parent | Thread | Link



dpcfmander
  User: dpcfmander
  Date: 2006-10-07 21:44 (UTC)
  Subject:   Maybe humour would help.
Funny, but obviously funnier to those of you who have used all of the languages.
Shoot yourself in the foot!
Reply | Thread | Link



(no subject) - (Anonymous)
Ben Cantrick
  User: mackys
  Date: 2006-10-08 04:55 (UTC)
  Subject:   (no subject)
I only have a main() function. I didn't see much point in modularizing when the code was supposed to be this simple:

main()
{
s1 = socket(addr1);
s2 = socket(addr2);

while(TRUE) {
s1.read(&b1);
s2.read(&b2);

if(b1.count > 0) { s2.write(b1); b1.count = 0; }
if(b2.count > 0) { s1.write(b2); b2.count = 0; }
}
}


I just didn't count on having to wrap every line except "while(TRUE)" in a try/catch(/finally).
Reply | Parent | Thread | Link



Ben Cantrick
  User: mackys
  Date: 2006-10-08 05:03 (UTC)
  Subject:   (no subject)
The rule of thumb in Java is that you should have 10 final blocks without catches for every catch you have.

Doesn't work here. I must do something ONLY when an exception occurs. A finally block executes whether the exception happened or not.
Reply | Parent | Thread | Link



browse
May 2015