PROPOSAL: Improved Support for Optional Object Behaviors at Runtime (original) (raw)

Alan Snyder javalists at cbfiddle.com
Sun Mar 29 13:26:53 PDT 2009

Derek,

I will respond to your two points in separate messages.

You raise the issue that this proposal will weaken the guarantee in current Java that requires the caller of a method to consider (catch or declare in its own signature) the exceptions thrown by the methods that it calls.

I do not see how this would happen. Any method that declares a checked exception will require an exception handler or declaration, as in current Java. Any method that throws an unchecked exception will not, as in current Java.

Your example method getFoo2() does not declare that it throws a checked exception. Thus, as in current Java, there is no guarantee that the caller will consider the possibility of an exception being thrown by this method. If you want callers of your API to be forced to consider a possible exceptional condition, you must declare the methods to throw checked exceptions. There is no change here.

Yes, it is true that someone could write a method that throws an unchecked exception when it would have been more appropriate to throw the superclass checked exception. That does not seem any different than throwing a Runtime exception when a checked exception would have been more appropriate. It is bad programming, for which there is no help from the compiler.

Anyway, I'm sure that you wouldn't put a method like that in your API, and I'll bet you're not likely to do it by mistake (which is where compiler support would be relevant).

Alan

On Mar 28, 2009, at 5:43 PM, Derek Foster wrote:

Although I appreciate what you are trying to do with this proposal, and I have certainly been inconvenienced by the problem that you are trying to solve, I am also very concerned with unintended consequences of your proposal. Your proposal describes its intended effect, and it certainly seems able to solve that use case, but does not seem to really delve into other impacts of this change in behavior which might be less positive.

One of the reasons I typically use checked exceptions in programs is to ensure that all callers of an API must consider and handle the various error conditions that can occur. Thus if I have a method like:

void getFoo() throws FooDoesNotExistException;

I can be assured that anyone who calls getFoo() will be forced to consider what to do if the Foo object does not exist. They may choose to ignore the error condition, but at least they will have been forced to consider it (by adding a 'catch' clause somewhere in the program for it or one of its supertypes). This is one of the most important reasons to use checked exceptions in the first place: They allow the compiler to do what amounts to essentially a compile-time proof that all checked exceptions will eventually be handled by someone.

Your proposal seems to have the potential to break this guarantee, so that someone could have a method like:

void getFoo2(); // throws UncheckedSubtypeOfFooDoesNotExistException;

then if I call it in my code:

Foo getStuff() {     return getFoo2(); }

I am never forced to add a catch clause for FooDoesNotExistException anywhere.

More information about the coin-dev mailing list