Exception programming difficult

[Paulo Pinto]

Am 12.08.2012 08:22, schrieb Marco Leise:
> I read both articles and while Bruce Eckel's text read a bit like repeated "swallow exception" to "avoid reams of code" I found the interview insightful. Both aren't entirely negative on checked exceptions and Hejlsberg actually wants them:
>
>    [Anders Hejlsberg]: "And so, when you take all of these issues, to me it just seems more thinking is needed before we put some kind of checked exceptions mechanism in place for C#. But that said, there's certainly tremendous value in knowing what exceptions can get thrown, and having some sort of tool that checks."
>
> The arguments against the Java model were:
>
> 1) The programmer, annoyed by the compiler, swallows exceptions with empty catch clauses and forgets about them.
>
> I think _if_ the intention is to get back to it later, you can always write "// TODO: handle the missing icon, by loading a stock icon from the OS". On the other hand, if you just don't want to declare the thrown exception, then this is wrong thinking in my opinion. Usually when I am in this situation in Java it makes me think about the error handling: Can this error be handled gracefully? If so, right here or should it bubble up? Where is the right level to handle it? At the end of this process I have the positive feeling that I got the error handling right.
>
> 2) Versioning; a change in a function may add a thrown exception, breaking client code. Often those clients want to ignore any exceptions (and pass them on).
>
> Ok, accepted. The client code would have to change its "throws" list for no perceivable benefit.
>
> 3) Declaring the thrown exception doesn't scale well when you call into multiple subsystems that each throw different exceptions, where you would end up declaring dozens of thrown exceptions.
>
> I frankly have to say that I never worked on that big projects, that I had to declare 40 thrown exceptions. And the question may be asked if you should just wrap the exception into another at that point, because you obviously reached a granularity at which the finer details of the sub system failures have become secondary.
>
>
> So does it all boil down to the potentially long and cascading list of "throws"?
> This is not a first grade language issue, I realize that. It's just when you come across it and find yourself documenting the thrown exceptions in DDoc where they aren't checked or anything, it cries for a solution. The solution current languages take seems to be "let the exceptions slip through, more often than not you don't handle them anyway".
> How can we reap all the benefits, but avoid the manual listing of all thrown exceptions?
>

I have a large experience in JVM and to some extent .NET enterprise 
projects. These projects have a multi-site component usually in three
development sites, scattered around Europe and Asia, having from 30
up to 300 developers on project.

To keep costs per team member low, not everyone on the projects is a top 
coder, many are on their first or second big project.

Throws in Java method declarations are reduced to "throws Exception", or
"throws RuntimeException" with the real exception being wrapped in a 
RuntimeException.

Many places where the exceptions occur are handled like

try {
   // ...
} catch (Exception e) {
  e.printStackException(); //TODO: fix later (Like you describe)
}

Sure we try to fight against this type of code, but at the end of the 
day, there are many other issues to solve, and this type of code gets 
low priority as fixing it does not make money.


Checked exceptions are a failed experiment, and I surely hope that D 
does not get them.

It is a bit like the arguments about manual memory management, sure good
coders are able to make proper use of such abstractions, but in real 
life, projects seldom have real good coders on their teams. And when 
they have them, there are many other issues to take care of.

--
Paulo