Exception programming difficult

[SomeDude]

On Sunday, 12 August 2012 at 06:22:37 UTC, Marco Leise wrote:
> 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?

My experience and conclusions are very similar to yours. I would 
simply add that   the versioning problem simply is a change of 
interface. The compiler will force you to add a throws clause to 
your method signature if your code is likely to throw a new kind 
of exception (unless you handle it yourself). So you very well 
know you are making a breaking change, and that you risk 
infuriating your customers because of this. So I find it to be a 
fairly weak argument.