Anders Hejlsberg says, "The concern I have about checked exceptions is the handcuffs they put on programmers. You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren't helping them any."

Read this Artima.com interview with C# creator Anders Hejlsberg:

http://www.artima.com/intv/handcuffs.html

What do you think of Ander's comments?

I haven't decided exactly where I fall in the checked/unchecked exception debate, but I can't fully agree with the versioning issue presented here.

Anders says that if an interface is changed to add a new exception then all existing clients are broken. The argument is that most clients aren't actually handling the exceptions anyway, they're letting them get handled farther up the stack.

In general a component or subsystem that can throw many different exceptions should provide a base exception class. Methods that wish to defer handling of exceptions can then add "throws SomeBaseException" and accomplish two things: deal with any current and future subtypes of SomeBaseException; and make it explicit that this method does not try to handle that set of exceptions. Methods that *do* need to deal with one or more of the possible exceptions can catch the ones needed (and still declare "throws SomeBaseException", if that's the desired behaviour).

On the other hand, we've all seen lots of code with "throws exception" and those empty catch clauses. This does suggest a problem with the feature. Rather than discarding it altogther, perhaps there's some way to encourage users to use it properly?

> Rather than
> discarding it altogther, perhaps there's some way to
> encourage users to use it properly?

What is the "proper usage" then? I think that Anders might have been saying that a big problem with the Java implementation is that there is no good proper usage.

I agree - I think the scalability and versionability problems he presents here are symptoms of an API design that exposes clients to too much internal detail.

Methods that throw multiple checked exceptions are assuming that the client will want to treat these differently (and that this desire is important enough to justify numerous catch blocks).

In some cases, there may be a realistic expectation that the client but in many cases not - as Anders implies with his comment that the finally block is the important part of exception handling.

A common root exception in the hierarchy (e.g. MyApiException) isn't always possible, either, as the root cause exception might be from another API, such as FileNotFoundException (and creating MyApiFileNotFoundException extends MyApiException is crazy).

A way of dynamically composing a hierarchy would help, that way I can throw a single exception, MyApiException, and clients can designate if they want to handle these when they're caused by FileNotFoundException. The Throwable.getCause() seems a likely candidate. I'm not really suggesting a language revision, but to illustrate my point:


try
{
myApi.go();
}
catch( MyApiException e whencausedby FileNotFoundException )
{
}
/* otherwise, MyApiException isn't caught at all */
finally
{
}


You may be interested in the discussion on this article at LtU: http://lambda.weblogs.com/

I agree. Also it is a bit hard to realize the Exception numbers like 40 - 80 Exceptions in an application. Can anybody please let me know if this is the case in huge systems? Then the exception design should consider having a common base class for the system.

Most of the time, the Exceptions are used as a means to convey an appropriate message (The cause for the abnormal behaviour) to the end user/client. The actual error message can be embedded into the Exception instance in the code block where Exception actually occurred. So that the client can display this message using the e.getMessage(). If the catch block should be doing something more than mere displaying of the message, then as Prescott pointed out, getCause() should be an appropriate candidate. But this concept of checked Exceptions cannot be avoided altogether. Atleast it ensures that some good developers would end up handling it :-) .

Nowadays exceptions seem to have removed return values as a method of indicating success/failure or an unexpected event. (In some ways I guess its does this cleaner and simpler.) However I tend to restrict the use of exceptions for implementing 'exceptional use cases' and stick with return values to handle errors and such. Is it possible that people are just over using exceptions or using them for the wrong purposes? (Especially with respect to the versioning problems)

Hello! Have we forgotton about semantic distances? I think anyone who suggests increasing it, should read The "Pragmatic Programmer: From journeyman to Master" or similar book.

A error that is not handled where it occurs, is often not handled at all. This is especially true for programmers with a sloppy style of their art. Sloppy programmers, resistant to learning how to do it right, won't do error handling properly anyway.

If exceptions are not handled locally, how does the main message loop get to know how to deal with exceptions, especially in the large systems case. A FileNotFound Exception might be innocent or it disastrous. Should the main message loop inspect the stack trace, and decide what to do?

What if a subsystem is poorly implemented, (where throwing it out is not an option). Such subsystems act as snipers, and in programming languages without checked exceptions you will not have good chances to discover what errors/exceptions might be thrown before they blow up in your face production time.
Systems with local try - catch curly curly, should not be reused at all: they will never behave in a larger perspective. This is bad bad programming, and is not worth struggling with.

I think condemning checked exceptions as a whole is a mistake. Anders Hejlsberg very clearly explains the results you get when you make everything a checked exception. But I think it's more subtle then "checked exceptions are evil". There is a real use for checked exceptions. I quote Rod Johnsons book:

Question: Should all callers handle this problem? Is the exception essentially a second return value for the method?

Example: Spending limit exceeded in a processInvoice() method.

If 'yes': Use a checked exception and take advantage of Java's compile-time support.

Question: Will only a minority of callers want to handle this problem?

Example: JDO exceptions

If 'yes': Extend java.lang.RuntimeException. This leaves callers the choice of catching the exception but doesn't force them to.

Question: Did something go horribly wrong? Is the problem unrecoverable?

Example: A business method fails because it can't connect to the application database.

If 'yes': Extend java.lang.RuntimeException. I do think a java.lang.Error would be more suitable here. According to javadoc an Error signals a "abnormal condition that a reasonable application should not try to catch".

end of quote

groeten uit nederland
Joost

> ...in programming languages without checked exceptions
> you will not have good chances to discover what
> errors/exceptions might be thrown before they blow up in
> your face production time...

This argument sounds almost identical to the one used against languages (such as Python) that don't use compile time type checking. That being the case, then the reposte will also be similar... test driven development, if done properly, should be as effective in dealing with unchecked exceptions as it is in dealing with untyped variables.

Poor programmers will always cause problems. I don't think that you can design a system that deals with them efficiently but that's another story.

Vince.

How about having "unexpects" keyword ?

void methodNumberOne() throws ACheckedException {
...
}

void methodNumberTwo() unexpects ACheckedException {
...
methodNumberOne();
...
}

The compiler then compile methodNumberTwo() as like:

void methodNumberTwo() {
try {
...
methodNumberOne();
...
}
catch(ACheckedException e) {
throw new UnexpectedException(e);
}
}


Of course, UnexpectedException is a RuntimeException descendent. Is this a good idea ? This way you can explicitly declare what exceptions are unexpected and the code is totally unprepared for those situations.

I can see two problems in not having checked exceptions.

1. How do you know that the method throws an exception that you are meant to handle. Especially when you write code that uses some toolkit than in turn uses someother toolkit.

I know that exceptions can be documented in C# but can you find the possible exceptions that may be thrown all the way down the call tree?.

2. It must seem to ecourage sloppy coding, in that to reduce try/catch noise one doesn't bother to include any and let the caller worry about it. Almost like the VB hell of "ON ERROR RESUME". Of course one can have sloppy code with checked exceptions and the loud noise that might come from try/catch proliferation.

As for versioning I'd have thought that if you change the signature/contract of a method then the caller has to defend against it instead of quietly ignoring the fact that the method may now fail because a new reason.

We only have to look at the amount of software outthere that complains using dialogs "Can't do xxx" then "Unable to ..".

> A way of dynamically composing a hierarchy would help,
> that way I can throw a single exception,
> MyApiException, and clients can designate if
> they want to handle these when they're caused by
> FileNotFoundException. The
> Throwable.getCause() seems a likely
> candidate. I'm not really suggesting a language revision,
> but to illustrate my point:
>
>
> try
> {
> myApi.go();
> }
> catch( MyApiException e whencausedby FileNotFoundException
> )
> {
> }
> /* otherwise, MyApiException isn't caught at all */
> finally
> {
> }
>

Some kind of generics can help here. If Exception was declared as having a generic cause parameter we could write (assuming Some<A> extends Some<B> if A extends B):


try {
myApi.go();
} catch(MyApiException<FileNotFoundException> e) {
} catch(MyApiException<IOException> e) {
} finally {
/* otherwise, MyApiException isn't caught at all */
}


> Adding a new exception to a throws clause in a new
> version breaks client code. It's like adding a
> method to an interface.

Exactly! This is what you want to happen. If you think it's important enough to be part of the contract (in the throws clause of your API), then you want client code to break. If not, throw a RuntimeException.