tags:

views:

126

answers:

4

In my Java code, I occasionally run into situations where I have to catch a checked exception from a library function that I'm pretty sure can't occur in my use case.

Also, when coding, I sometimes notice that I'm relying on certain inputs from other modules (my own) to have or not have particular features. For example, I might expect a string to be in a certain format etc. In these situations, I would often put in a verification step, although I control the code that send the input myself.

At the moment, I'm working on a quite complex product that I want to be very reliable. Among other things, I want it to collect information from caught exceptions and automatically file bug reports. For the above two scenarios, I therefore defined an (unchecked) "ProbableBugException", that tells me I made a mistake in the code delivering the input data.

Is that a) stupid, b) paranoid or c) good practice? This is going to be subjective, I'll put up three wiki answers so we can vote away without rep warping.

ETA: Thanks to Svend for pointing out that Java has assertions, I didn't realize that. Assertions are actuall pretty much what my question was about, but I only knew them from C and have never used them there.

+2  A: 

It's stupid, because:

  • the exception should be much more specific, like InvalidInputException
  • you should think harder about the input side, it's likely that it's shaky if you feel you need that kind of exception
Hanno Fietz
OK...'stupid' might be harsh, but if you control the input, use asserts. That's what they're for. As for checked exceptions from library code, well, you have to remember "It's your fault" - http://www.codinghorror.com/blog/archives/001079.html . Catch the exception, report it, and then dig in to see what you did wrong.
Harper Shelby
Well, in that case, I'm fine with the harshness. :-) I have a tendency to overengineer when I work with Java, that can be pretty hard to fight.
Hanno Fietz
+1  A: 

It's good practice, because:

  • you might have a coworker coding on the input side and the two of you might have misunderstood each other
  • if you make a mistake, fixing it becomes trivial
  • in situations where the input side is a plugin of some sort, it helps the plugin developers (who might be external) to deliver correct input.
Hanno Fietz
+4  A: 

I'm thinking that using an assert is what you really want there ("probably bug").

http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

Svend
Thanks, I didn't know Java had them. Yes, it's pretty much what I want.
Hanno Fietz
The problem with assert is that by default is disabled at runtime. While it is a good practice to use asserts it is not all the time the recommend, especially in a library because you may never know if the application will have the assertions enabled. I don't think throwing a special exception in this case can be considered stupid or paranoid.
adrian.tarau
Well, explicitly throwing an AssertionError amounts to practically the same as my custom exception and is independent of assertions being enabled. If a library function puts me in a catch block that I never expected to be in, I also find "throw new AssertionError" slightly more readable than "assert false".
Hanno Fietz
A: 

I always expect the unexecpected.

I often have code like this : ( $div will never be 0 into my code )

if( $div != 0 ) {
   $var = $var2 / $div;
} else {
    /*
     * It should never happen
     */   
    throw Exception( 'relevant message' );
}

I always protect myself from me and the others

Luc M
Any particular reason you don't use assert here?
DJClayworth