Re: Checked Exceptions
On 14-12-2009 14:22, Leif Roar Moldskred wrote:
I'd like to see the "checkedness" of exceptions be separated from the
class hierarchy of Throwables and instead be declared when you throw the
exception. After all, whether or not an error should cause a checked or
unchecked exception depends more on where in the code it occurs than on
what the error is: there is no reason why an IllegalArgumentException from
input validating code should be unchecked, as the cliend code of that
_should_ know how to deal with that exception. On the other hand, if the
IllegalArgumentException occurs deep down in the business logic where it's
assumed that the data has all been validated and is clean, it makes sense
to throw it as unchecked: none of the immediate code would have any idea
what to do anyway.
>
> "throw new FooException( "Bad thing happened" ) as unchecked" or
something
> in those veins.
I don't like the idea of having throwchecked and throwunchecked. It
could become very messy with the same exception being both.
I seems quite fair to me that the type carry the information whether
it is checked or not. If necessary just create two types.
I don't like the extends RuntimeException => unchecked either. @Checked
and @Unchecked would be much nicer. But annotations did not exist back
then. And now it is too late.
To prevent lazy programming, let us add the rule that a method also have
to declare all unchecked exceptions which are thrown _directly_ from
within that method (i.e. thrown by an explicit throw statement in the
method body.)
Does not make sense to me.
Next, give us an implicit, method-level try block: allow us to have the
method block be followed by catch blocks and a finally block:
public void myMethod( ) throws MyException {
...
} // end myMethod( )
catch( FooException ex ) {
throw new MyException( ex );
}
finally {
System.out.println( "myMethod exited." );
}
Does not make sense to me. The code could just as well be inside
the method.
Then, give us some way to handle more than one type of exception in the
same catch statement. "catch( FooException, BarException, WeirdException ex ) { }"
That has been proposed before. I guess it is OK.
or, hell, why not re-use the switch syntax?
catch( IOException ex ) {
case FileNotFoundException: logFileNotFound( ); break;
case EOFException: logUnexpectedEof( ); break;
default: logOtherIOError( );
}
catch( Exception ex ) {
case FooException:
case BarException: logFooBarError( ); break;
case WeirdException: logWeirdError( ); break;
default: logBadThingHappened( ); throw ex as unchecked;
} // end catch( )
Test on type is an anti-OO thing.
Arne