Checked Exceptions [Java Programming]

Prev: how to kill a java thread by force?
Next: X11 based GUI toolkit for java on unix AND windows

From: Arved Sandstrom on 14 Dec 2009 05:46

If I read one more blog about what a new language should have (*) where
the author can't wait to show how "in" he or she is by excoriating
checked exceptions I'll probably write a new blog "Stupid New Language
Blogs are Considered Evil." :-)

Seriously, get over it already. The supposed anguish that checked
exceptions cause - namely, that you can't easily ignore them - is
exactly the point. I myself have never noticed that this is all that
much extra work. And what I *have* noticed - time and time again - is
that an OO language that has only unchecked exceptions leads in general
to poor error handling. But that's just a real-world observation: if it
happens to conflict with theory who am I to argue with blog theoreticians?

Thank you for your attention, and good morning.

AHS

* You know Java is pretty successful when everyone seems to use it as a
starting point for this discussion, even when they criticize it
savagely. Java is like democracy - apparently full of warts but nobody
can devise anything better that keeps as many people reasonably happy.

For the purposes of these "next language" discussions I consider C# to
be a near-Java. Although personally I do prefer C#.

From: Andreas Leitgeb on 14 Dec 2009 07:40

Arved Sandstrom <dcest61(a)hotmail.com> wrote:
^^^^^^^
> Although personally I do prefer C#.

Is it a bias, or just absence of anti-bias? :-)

From: Lew on 14 Dec 2009 09:04

Arved Sandstrom wrote:
> If I read one more blog about what a new language should have (*) where
> the author can't wait to show how "in" he or she is by excoriating
> checked exceptions I'll probably write a new blog "Stupid New Language
> Blogs are Considered Evil." :-)
>
> Seriously, get over it already. The supposed anguish that checked
> exceptions cause - namely, that you can't easily ignore them - is
> exactly the point. I myself have never noticed that this is all that
> much extra work. And what I *have* noticed - time and time again - is
> that an OO language that has only unchecked exceptions leads in general
> to poor error handling. But that's just a real-world observation: if it
> happens to conflict with theory who am I to argue with blog theoreticians?
>
> Thank you for your attention, and good morning.

Amen, brother!

People who excoriate checked exceptions don't understand how to write APIs
dictatorially or the value thereof. They are blaming the language instead of
the real "culprit", the API author. Checked exceptions are part of the method
declaration. That means that they are there not because the language designer
said so, but because the method designer said so. They must have had a
reason. Had checked exceptions not existed, they'd've not been able to
express that reason in a compiler-enforced way.

Thank goodness Java has checked exceptions available so that the API author
can choose to use them.

--
Lew

From: Joshua Cranmer on 14 Dec 2009 09:48

On 12/14/2009 05:46 AM, Arved Sandstrom wrote:
> Seriously, get over it already. The supposed anguish that checked
> exceptions cause - namely, that you can't easily ignore them - is
> exactly the point. I myself have never noticed that this is all that
> much extra work. And what I *have* noticed - time and time again - is
> that an OO language that has only unchecked exceptions leads in general
> to poor error handling. But that's just a real-world observation: if it
> happens to conflict with theory who am I to argue with blog theoreticians?

Quick: what does Java throw if it can't open a file for reading?
What does C++ throw?

> For the purposes of these "next language" discussions I consider C# to
> be a near-Java. Although personally I do prefer C#.

Considering that my first introduction to C# was as the language of
choice for a programming project due in a fortnight, I much prefer Java.
Especially Swing.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

From: Leif Roar Moldskred on 14 Dec 2009 14:22

Arved Sandstrom <dcest61(a)hotmail.com> wrote:
>
> Seriously, get over it already. The supposed anguish that checked
> exceptions cause - namely, that you can't easily ignore them - is
> exactly the point. I myself have never noticed that this is all that
> much extra work. And what I *have* noticed - time and time again - is
> that an OO language that has only unchecked exceptions leads in general
> to poor error handling.

While checked exceptions are a good idea, Java _does_ make it unnecessarily
cumbersome to work with them. There's no clean separation between checked
and unchecked exceptions, the concept of unchecked exceptions have been
muddled up with the concept of runtime exceptions (most exceptions thrown
by the runtime should be unchecked, but that's not a fundamental
relationship), and because of the try / catch syntax it gets awkward to
write common error-handling code.

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.

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.)

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." );
}

Then, give us some way to handle more than one type of exception in the
same catch statement. "catch( FooException, BarException, WeirdException ex ) { }"
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( )

--
Leif Roar Moldskred

| Next | Last
Pages: 1 2 3 4 5
Prev: how to kill a java thread by force?
Next: X11 based GUI toolkit for java on unix AND windows