Re: can't throw
On 09/15/2012 12:33 AM, Leif Roar Moldskred wrote:
Personally, I think it was a design flaw to tie the checked /
unchecked to the class hierarchy. An exception's class corresponds to
a particular error type, but the severity of a particular type of
error, and wheter we can expect the client to be able to recover from
it or not, depends on the context.
The choice of checked / unchecked should be made statically _at the
point of the throw statement_,
Let's see what the consequences of this would be:
1. we need new syntax (e.g. a new keyword), in order to make that
distinction. So it's either
throw checked new IllegalStateException("You can't do that right now.")
throw_checked new IllegalStateException("You can't do that right now.")
2. The complier needs to enforce all exceptions thrown with "throw
checked" are declared in the throws clause.
OK so far, no issues there.
3. Now, assume we have a section of code which throws the same exception
type checked and unchecked. That section is embedded in a try block.
Now we have a catch clause for this exception type attached to the try
block. This prompts the question: which of the thrown exceptions does
the catch block handle - only the checked throws or also unchecked throws?
3a. It handles both. This leads to the unsatisfactory situation where
the same catch block needs to handle programmer errors (now
RuntimeException and subclasses) and other errors which are actually
expected. That's not good since programmer errors (and catastrophic
situations like OOM are usually handled quite close to Thread.run, i.e.
further up the call stack.
3b. The programmer can decide, so we need a new syntax again:
catch checked ( IllegalStateException e )
This will only catch checked exceptions. Do we now need an additional
syntax for "unchecked", e.g.
catch unchecked ( IllegalStateException e )
And what do we do if we want to cover both cases (e.g. because we just
want to print the error)? Do we then do this?
catch checked, unchecked ( IllegalStateException e )
Or do we use the current form to mean "catch both"?
catch ( IllegalStateException e )
In which way we resolve these questions it's obvious that one can easily
forget a keyword or make a different error so one ends handling other
exceptions than intended.
Given the fact that the type of exception also describes the type of
error and that in turn is related to the classification "programmer
error" / "no programmer error" I am not so sure whether the additional
complication your distinction at call site introduces is actually
worthwhile.
Kind regards
robert