next »

[Geti]

Sure, but more often than not I've seen "catch(Exception e) {}" or just letting the exception propagate upwards by tacking a throws statement onto the method signature (which pisses off anyone using your code because they have to do the same goddamn thing, especially in the case of "throws Exception").

Of course the IDE handles putting a better "bare minimum" in there (throws IOException, catch IOException e etc) but regardless of that I dislike exceptions.
My reasons are

• the code quickly becomes ugly due to all the syntactic overhead
• detecting the point of failure in a try/catch block longer than a few lines is a new breed of banality
• variables need to be forward declared to remain available outside of blocks (meaning you choose between yet more syntactic overhead and debugging frustration when something goes wrong in the middle of the block)

Compare

Code:

/* open a file */
FILE* f = fopen("some/filename", "r");
if(f != NULL) /* nothing went wrong */
{
  /* .. do stuff with the file .. */

  fclose(f); /* free the file resource */
  f = NULL;  /* null the pointer */
}

Code:

//forward dec so that this file is available outside
//the try/catch block
RandomAccessFile f = null;
//try to open the file
try {
  f = new RandomAccessFile(new File("some/filename"), "r");
} catch (IOException e) {
  e.printStackTrace();
}
//if that didn't fuck up and we have a valid file
if(f != null)
{
  //do something with file
  //try to close it
  try{
    f.close(); //why the shit can this fail?
    f = null; //null the ref if that didn't fuck up
  } catch (IOException e) {
    e.printStackTrace();
  }
}

I understand this example is _somewhat_ contrived, but seriously how hard is it to make opening using and closing a file for random byte access trivial?

While I understand why java wants to have catch all interfaces and all that jazz, they make writing average code using those interfaces a pain. The syntax of try/catch is dumb (if only because it fucks with indentation of a normal block saying open the file and do something with it), and everything throwing an exception does not help this issue (seriously, if there's an error in the equivalent of fclose() I don't want to know about it, it's either not my fault or I'm passing it null).
It seems like at some point one guy decided that exceptions were great and started throwing them everywhere, and everyone else humoured him and just made their code throw his exceptions to the point where http://grab.by/nGz2 .

On a positive note, Go's extra error return value is awesome and I wish Go was less of a ghost town development wise.

[Dacke]

I'm not arguing that the Java solution is the best. But I think that other languages are generally worse because they pretend that errors are not an issue. Java also lets you throw stuff to the top and multi-catch it if you just want to hack, which isn't that cumbersome.

The Go style actually gives you a similar amount of syntactic overload, because you are supposed to handle every error individually. Try/Catch is a bit more convenient (and as such less reliable) because it allows you to group errors together.

Your Java example is really strange, though. You do all sorts of unnecessary null stuff, create an extra class and degroup the exceptions for no apparent reason. If I'm not mistaken, the Java version of the C code with the same (unreliable) behavior would be:

Code:

try {
  RandomAccessFile f = new RandomAccessFile("some/filename", "r");
  /* .. do stuff with the file .. */
  f.close();
} catch (IOException e) {
   // Do nothing, just like the C-code
}

The exact same behavior, the same amount of code.

[Geti]

eclipse complains about f not necessarily being closed (resource leak) because of the short-circuit in the first try/catch if theres an IOException upon opening.
In a real case where you're doing stuff with the file (using methods that throw more IOExceptions) you'll either need to wrap the operations themselves in try/catches to avoid short-ciruiting the whole thing and not closing the file, or do the file close outside of that try/catch.

A kinda cleaner way to do it would be with a finally block I guess (same as you would with a mutex lock):

Code:

//try to open the file
try {
  RandomAccessFile f = new RandomAccessFile("some/filename", "r");
  //do stuff with the file here
} catch (IOException e) {
  e.printStackTrace();
}finally{
  try{ //to close it
    f.close(); //why the shit can this fail?
  } catch (IOException e) {
    e.printStackTrace();
  }
}

Still needs the try/catch in the finally because of the exception thrown by f.close().

In the C version, the file is "guaranteed" to be closed if opened, since the file handle is only non null if fopen succeeded.

Re: strange nulling: I'm in the habit of nulling references after I'm done with them to prevent inept group members from attempting to do things with them when they're still in scope but after they're closed or otherwise useless when writing java from uni, bad habit most likely

Re: the new File in there - whoops

The Go style allows you to simply ignore the returned error value in the event that you don't care about it, such as an error in closing a file resource using the standard functions for doing so.

[Dacke]

Ah, you're right! You do get those weird try-catch-finally-try-close-catch things, they are indeed ugly.

But I think that's more of a shortcoming in Java's file APIs, which are generally atrociously badly designed. When studying Java at university my teacher even spent a lecture talking about how badly designed they are.

[Geti]

Yeah I think that's more what I'm getting at. I just dont really like that I cant ignore the exceptions without being an asshole to anyone I work with and making _them_ catch it at some point, but it's not so bad with a relatively clean (or at least robust) API that isn't tossing exceptions left and right.

Either way, this is getting a little unfunny so I'm gonna head to bed, thanks for your thoughts on it either way. Interesting hearing about the way someone who does a lot more java programming than me sees it.

[Dacke]

I'm work as a Java programmer in Stockholm, so it's probably just Stockholm syndrome on my part

I think Java is a language where you have to learn lots of idioms and IDE-tricks in order to be comfortable. If you know what to do with the exceptions in a given situation it isn't that bad, but I still struggle to get it right at times. Error handling is hard, and try/catch is indeed pretty akward at times.
 
Well, goodnight!

[Overloaded]

Code:

self.fish;

I read almost every post of this topic. This topic is just so funny! xD

Oh, also:

Code:

other.wise;

[Dacke]

I just found a file named "sudo" in one of my source folders. It contained the command:

Code: (sudo)

/proc/sys/vm/drop_caches

I tried to flush my caches earlier. It didn't work and apparently I managed to create this file instead

Mad Linux skills!

[Eigen]

Code:

NSLog(@"\terrorCode = %@", errorCode);

[Quarry]

Escape characters, \terrorizing your since C

[Dr. Cooldude]

Code:

NSLog(@"\terrorCode = %@", errorCode);

Make sure NSA is not spying your computer or you'll be fucked.

[Quarry]

I'm sure they know that \ escapes the next char

[Dr. Cooldude]

I'm sure they know that \ escapes the next char

Unless some old politician sees it and flips his shit.

[Eigen]

That log line was from a iOS app I'm writing for a \terror organization. They need an app for keeping track of \terror identifiers. Their API is rather outdated (XML SOAP for crying out loud) so lots of \terror handling needed. The \nSA also gave me an horrible spec for a mobile app to begin with ..

Kidding.

SA - Software Architect

[Muz]

Ha, just found some stuff in the Android code.
http://developer.android.com/reference/android/os/IBinder.html#LIKE_TRANSACTION
http://developer.android.com/reference/android/os/IBinder.html#TWEET_TRANSACTION

[Dr. Cooldude]

Ha, just found some stuff in the Android code.
http://developer.android.com/reference/android/os/IBinder.html#LIKE_TRANSACTION
http://developer.android.com/reference/android/os/IBinder.html#TWEET_TRANSACTION

Haha, those developers at Google really have some nice sense of humor.

[Evan Balster]

Hard-coded vertices for a piano keyboard.  That was an hour well spent.

Code:

Sequencer::UI::UI(App *_app) :
	Interface(_app)
{
	//Draw a piano.  Yes, this is clearly a smart way to do this.
	const float YE = .8f, YT = .7f, YF=.3f, YB=.0f,
		XK=1.0f/7.0f, XE=1.0f/12.0f,
		XF[] = {.6f*XK,1.2f*XK, 1.8f*XK,2.4f*XK,
			3.5f*XK,4.1f*XK, 4.7f*XK,5.3f*XK, 5.9f*XK,6.5f*XK};

	//C
	octave.shape(WHITE).build
		(XK*0, YB)(XK*0, YT)(XE* 0,YE)(XE* 1,YE)
		(XF[0],YT)(XF[0],YF)(XK* 1,YF)(XK* 1,YB);
	//C#
	octave.shape(BLACK).build
		(XF[0],YF)(XF[0],YT)(XE* 1,YE)(XE* 2,YE)(XF[1],YT)(XF[1],YF);
	//D
	octave.shape(WHITE).build
		(XK*1,YB)(XK*1,YF)(XF[1],YF)(XF[1],YT) (XE* 2,YE)(XE* 3,YE)
		(XF[2],YT)(XF[2],YF)(XK*2,YF)(XK*2,YB);
	//D#
	octave.shape(BLACK).build
		(XF[2],YF)(XF[2],YT)(XE* 3,YE)(XE* 4,YE)(XF[3],YT)(XF[3],YF);
	//E
	octave.shape(WHITE).build
		(XK*3, YB)(XK*3, YT)(XE* 5,YE)(XE* 4,YE)
		(XF[3],YT)(XF[3],YF)(XK* 2,YF)(XK* 2,YB);
	//F
	octave.shape(WHITE).build
		(XK*3, YB)(XK*3, YT)(XE* 5,YE)(XE* 6,YE)
		(XF[4],YT)(XF[4],YF)(XK* 4,YF)(XK* 4,YB);
	//F#
	octave.shape(BLACK).build
		(XF[4],YF)(XF[4],YT)(XE* 6,YE)(XE* 7,YE)(XF[5],YT)(XF[5],YF);
	//G
	octave.shape(WHITE).build
		(XK*4,YB)(XK*4,YF)(XF[5],YF)(XF[5],YT) (XE* 7,YE)(XE* 8,YE)
		(XF[6],YT)(XF[6],YF)(XK*5,YF)(XK*5,YB);
	//G#
	octave.shape(BLACK).build
		(XF[6],YF)(XF[6],YT)(XE* 8,YE)(XE* 9,YE)(XF[7],YT)(XF[7],YF);
	//A
	octave.shape(WHITE).build
		(XK*5,YB)(XK*5,YF)(XF[7],YF)(XF[7],YT) (XE* 9,YE)(XE*10,YE)
		(XF[8],YT)(XF[8],YF)(XK*6,YF)(XK*6,YB);
	//A#
	octave.shape(BLACK).build
		(XF[8],YF)(XF[8],YT)(XE*10,YE)(XE*11,YE)(XF[9],YT)(XF[9],YF);
	//B
	octave.shape(WHITE).build
		(XK*7, YB)(XK*7, YT)(XE*12,YE)(XE*11,YE)
		(XF[9],YT)(XF[9],YF)(XK* 6,YF)(XK* 6,YB);

	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*1,YB)(XK*1,YF);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*2,YB)(XK*2,YF);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*3,YB)(XK*3,YT)(XE* 5,YE);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*4,YB)(XK*4,YF);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*5,YB)(XK*5,YF);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*6,YB)(XK*6,YF);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*7,YB)(XK*7,YT)(XE*12,YE);
}

And yes the program is as cool as it looks.

[Belimoth]

 

[Evan Balster]

For the curious, this is what it does: https://soundcloud.com/evan-balster/perilymph-test-demonstration

It's coming along very well.

[Impmaster]

Was it worth it