Better exception handling

[Brian Goetz]

People have probably been hesitant to reply because they have seen what 
happens when someone starts a discussion on checked exceptions (it's not 
pretty).  Let me just try to summarize where things are from the 
previous thousand such discussions....

Joe Duffy said just about everything there is to say about error models:

     http://joeduffyblog.com/2016/02/07/the-error-model/

The main takeaways are:

  - They are all unpleasant, but for different reasons that bother 
different people differently, and people tend to be unpleasantly 
religious about their favorite model, which makes reasoned discourse 
difficult;

  - Error models are a property not only of the language but of the 
ecosystem as a whole; if different libraries have different error 
models, they can't be composed.

To which I'll add:

  - For an opinion like "checked exceptions suck", it is very easy to 
convince yourself that this opinion is universally held.  It is not.  It 
is just that the people who hold this opinion (and there are plenty) are 
vocal about it, and the silent majority who think it's "meh, not great, 
but good enough" are quietly getting their work done and don't bother to 
engage in the argument.

Which is to say, Java has picked its model, and while we can complain 
about it (but not here, please), it is what we have, and it is not as 
bad as people would like to make it out to be. Much of the pain of 
checked exceptions is not intrinsic to the language mechanism itself, 
but to the way checkedness is determined (an exception is checked if it 
extends Throwable but not RuntimeExcpetion or Error) and by misuse of 
checked exceptions in early libraries, before we came to a better 
understanding of when to use one vs the other.  Even if the language 
offered help at the use site, the fact that InputStream::close throws a 
checked exception is still going to be a problem (what are you supposed 
to do, close it again?)

To your point, yes, there are things that could be done to reduce the 
syntactic pain of checked exceptions.  But, as you point out, 
straightforward try-catch expressions don't remove most of the overhead; 
they just trim around the edges. Exceptions are better than statements, 
so this is not nothing, but for most people, it would be met by "but 
that doesn't fix my problem."  There are more aggressive things that a 
"try" expression could do, but they would require deeper intrusion into 
other parts of the language, so this is not an "easy fix" (though still 
a viable avenue for exploration.)

(As an overlay that makes the problem even more difficult, the rhetoric 
over this particular topic is so toxic that it makes one less inclined 
to invest a lot of energy; it is virtually guaranteed that whatever we 
would propose would likely be met with such bile on the part of the 
haters, that I struggle to see a move that will actually make people happy.)





On 3/21/2021 4:20 PM, d3coder wrote:
> Try-catch expression would be really good feature, to avoid exception handling
> bugs, i'm writing code like this:
>
> MyObject myObject;
> try {
>      myObject = myObjectFactory.newInstance();
> } catch(IOException e) {
>      throw new CustomException("Can't fetch", e);
> }
> myObject.doSomething();
>
> Sometimes i do similar code, but with automatic resource handling, e.g.
> try(InputStream is = openStream())
>
> Any ideas how this could be made better? I though about try-catch expressions,
> but it's still a lot of a code; I've thought about helper method like
> getOrThrow(supplier, exception -> {}), but it's still feels like a half
> solution
>
> Maybe language can offer something like ? syntax or would be try-catch
> expressions enough?
>
>