Do I get bonus points for this code?

[EyeMWing]

No question, just stupid.

I do this for 500 ActionListeners in a row, with a different stupid never-to-see-the-light-of-day error message for each.

 

[notfred]

Are you bragging about your stupidity, or do find this comical?

 

[EyeMWing]

Originally posted by: notfred
Are you bragging about your stupidity, or do find this comical?

ini is an instance of a third party class which requires that I throw an IOException somewhere in there. Point being that I don't need to use it - at all, but it needs to be present to make the compiler STFU.

 

[AFB]

Maybe I'm missing something, but I don't see a reason why you would need the try/catch block at all if they only place it catches on is your exception. How does ini force you to throw an exception? I don't quite follow.

 

[EyeMWing]

Originally posted by: amdfanboy
Maybe I'm missing something, but I don't see a reason why you would need the try/catch block at all if they only place it catches on is your exception. How does ini force you to throw an exception? I don't quite follow.

ini throws an exception - I either need to handle one, or throw one, or the damn thing won't compile. I can't take my normal cop-out and have the object throw one since this ActionListener is an inner class and I'm 99% certain that that's syntactically impossible, but feel free to correct me if I'm wrong. So I both handle the exception and include a token stupid-throw because I was bored and to give the code maintainers something to do.

 

[kamper]

Originally posted by: EyeMWing

Originally posted by: amdfanboy
Maybe I'm missing something, but I don't see a reason why you would need the try/catch block at all if they only place it catches on is your exception. How does ini force you to throw an exception? I don't quite follow.

ini throws an exception - I either need to handle one, or throw one, or the damn thing won't compile. I can't take my normal cop-out and have the object throw one since this ActionListener is an inner class and I'm 99% certain that that's syntactically impossible, but feel free to correct me if I'm wrong. So I both handle the exception and include a token stupid-throw because I was bored and to give the code maintainers something to do.

Umm, either your ini class declares that it throws a non-RuntimeException from one of those methods or it doesn't. If it doesn't, you don't have to catch anything. If it does, you have to catch it but you don't have to throw anything. It doesn't work both ways.

If this 3rd party class does throw an IOException it's probably for a good reason. When you catch it you should probably log it and/or wrap it in some form of RuntimeException and throw it again. Swallowing exceptions silently makes for a difficult to debug program and calling System.exit() almost anywhere except within short range of a main() method is very bad practise.

And if you have to copy the same code over 500 times you really need to rethink why.

 

[EyeMWing]

Originally posted by: kamper

Originally posted by: EyeMWing

Originally posted by: amdfanboy
Maybe I'm missing something, but I don't see a reason why you would need the try/catch block at all if they only place it catches on is your exception. How does ini force you to throw an exception? I don't quite follow.

ini throws an exception - I either need to handle one, or throw one, or the damn thing won't compile. I can't take my normal cop-out and have the object throw one since this ActionListener is an inner class and I'm 99% certain that that's syntactically impossible, but feel free to correct me if I'm wrong. So I both handle the exception and include a token stupid-throw because I was bored and to give the code maintainers something to do.

Umm, either your ini class declares that it throws a non-RuntimeException from one of those methods or it doesn't. If it doesn't, you don't have to catch anything. If it does, you have to catch it but you don't have to throw anything. It doesn't work both ways.

If this 3rd party class does throw an IOException it's probably for a good reason. When you catch it you should probably log it and/or wrap it in some form of RuntimeException and throw it again. Swallowing exceptions silently makes for a difficult to debug program and calling System.exit() almost anywhere except within short range of a main() method is very bad practise.

And if you have to copy the same code over 500 times you really need to rethink why.

The same code is duplicated 500 times because I have 500 GUI elements which all do different things. Only the basic structure is the same and that they each call ini.save at least once. If you're aware of some way to have 500 different actionlisteners without creating 500 of them, I'm DEFINITELY open to suggestion.

The IOException is thrown for one reason. The .save method requires a certain file to be writeable. I check this elsewhere in my OWN code, and as such the exception is totally unneccessary (except in the absolutely broken, retarded, numbskullish event that some asstard changes permissions while the program is running, and IMHO solving that problem should be left up to Darwinism)

And yes, you're right, I don't need the if(true)/else throw, but it keeps me from getting bored out of my head by allowing me to write retarded exception messages.

 

[kamper]

And what happens a year down the road when someone else has to come along and maintain this code and wonders why you've put this completely arbitrary construct in 500 times, especially when you throw an exception for no apparent reason. I hope there are at least some explanatory comments in the real code.

As for the System.exit(), I don't think you should be making the assumption that the same check will always be performed. Reliance on an outside factor like that requires that the code is never used in a different context or that there are no bugs in the code that does the checking or that something odd won't happen in between when the check is made and this code is called. If something ever does go wrong the correct behaviour might very well be drastic, throw an exception that might not be caught until a long ways down the stack, at least something that allows the possibility of recovery. Is your application really not capable of running anymore if an IOException is thrown?

If I had to repeat this pattern 500 times I would make a BaseActionListener that has another method that calls the "dangerous" method and traps the exception. It may not be much but I count 7 lines of code that can be saved (7*500 = 3500 which is a significant amount of code). Then, when you decide you want to tweak the implementation even a little bit you don't have to track down all 500 instances of it. You don't even need a new class, you could just do it in a static method.

But enough of this, it's your code and it's none of my business what you write.

 

[Barnaby W. Füi]

I am VERY skeptical that there is a good reason to repeat a block of code 500 times.

 

[EyeMWing]

Originally posted by: BingBongWongFooey
I am VERY skeptical that there is a good reason to repeat a block of code 500 times.

I suppose I could have simplified the implementation by not doing design work at 7AM (and now that I've realized that I can simplify things a little bit, it will be applied to the future 1500-or-so times I would have duplicated that block. Of course, it's only going to be a few lines shorter per-chunk.

Furthermore, let me emphasize that it's not the CODE that's duplicated 500 times, each instance is different, but instead the STRUCTURE that's duplicated 500 times. I'm crazy, not stupid.

 

[Barnaby W. Füi]

Yeah, I know, it's the same basic thing repeated with minor changes. At the very least, for something like that, you should probably use a script to generate the code, or something along those lines.

As nasty as C/C++ macros can be, they can also be a godsend. I would hate to have had to hand-code this. Instead I just factored out the repetetive crap into macros and this is the source I deal with.