Re: Java language and library suggestions
Tomas Mikula wrote:
....
But if I know that I provide the correct input (and if not, I want my
program to crash, because I consider it a programming error), I still
have to write these extra lines of code. Do it 4 times in one method
and the readability of the code suffers a lot. Example, when I want my
program to crash on wrong input, is when the input comes from the
configuration file, or is hardcoded in the program code. Such input is
parsed only at the application startup and it's OK to crash. So I
don't want to catch the exception, but I don't want to declare it all
the way up the call hierarchy either.
The best solution I've found so far for this problem is to create my own
RuntimeException subclass:
try{
// whatever
}(catch IOException e){
throw new MyApplicationInternalException(e);
}
MyApplicationInternalException is strictly reserved for conditions that
indicate the application itself went wrong, such as an Exception that
should not be possible. Because it subclasses RuntimeException it does
not need to be declared in each method.
It has a constructor that is something like:
MyApplicationInternalException(Exception e){
super("Internal error in my application: "+e.toString(),e);
}
It can either be caught at the top level and suitably reported, or let
cause the application to crash.
Note that you *have* to do something to distinguish the "cannot possibly
happen" exceptions. It is not usually possible for the compiler to tell
whether you intended to have code enforcing the relevant conditions or not.
Patricia