Checked vs unchecked exceptions

[Eugene Wissner via Digitalmars-d]

http://forum.dlang.org/post/ullvxbfqeuztwecxcygb@forum.dlang.org

On Sunday, 25 June 2017 at 17:38:14 UTC, mckoder wrote:
> I am disappointed that D doesn't have checked exceptions.
>
> C++ and C# also don't have checked exceptions. Java has checked 
> exceptions. Having programmed extensively in all these 
> languages I can say with confidence that checked exceptions is 
> the most important thing missing in C++ and C#. Around the time 
> C# was released there was a lot of debate around the topic of 
> checked vs unchecked exceptions and this created an impression 
> that Java's use of checked exceptions was "controversial". In 
> fact it is a feature every modern language should have.
>
> Exceptions that can be thrown by a method should be part of the 
> contract of that method. Changing the list of the list of 
> exceptions that can be thrown by a method is just like changing 
> the parameters of the method. This is something that should 
> cause calling code to fail to compile. This will allow you to 
> inspect the calling code and decode how to deal with the new 
> exception.
>
> When the exception that can be thrown by a method is not known 
> you don't know what exceptions to catch and what exceptions to 
> pass through to callers. You can't rely on documentation 
> because the documentation is not verified be the compiler and 
> so is not reliable. All you can do is to run the program a few 
> times, see what exceptions you get and handle them. Even if you 
> are able to determine the full list of exceptions using this 
> strategy, a future revision of the called method can throw a 
> new exception and cause your program to crash. As a result, in 
> large C# code bases it is common to see catching the base 
> Exception class because this is the only way to prevent a 
> crash. This causes exceptions to be "swallowed" because higher 
> level code that is actually prepared to handle certain 
> exceptions never get the exception.
>
> With Java this problem doesn't exist. When you call a function 
> you know exactly what exceptions can be thrown and you can 
> catch (or pass through) exactly those exceptions. There is no 
> need to catch the base exception class.
>
> When you have multiple implementations of an interface (such as 
> database connectivity layer) and each of those implementations 
> can throw a completely disjoint set of exceptions there is no 
> way to write polymorphic code that can recover from errors.
>
> Anders Hejlsberg, designer of C# doesn't think people care to 
> catch specific exceptions, which is why C# doesn't have checked 
> exceptions. (See http://www.artima.com/intv/handcuffs.html ) 
> "They're not going to handle any of these exceptions. There's a 
> bottom level exception handler around their message loop. That 
> handler is just going to bring up a dialog that says what went 
> wrong and continue." Also: "The exception handling should be 
> centralized.." In other words, he thinks all people want to do 
> with exceptions is catch the base Exception class and display a 
> message. I have a lot of respect for Anders Hejlsberg (my first 
> programming language was Turbo Pascal) but he is completely 
> wrong on this topic.
>
> Regarding the versioning issue discussed by Anders Hejlsberg, 
> my response is that throwing a new exception is like changing 
> the signature of a function. You want callers to be alerted 
> that they need to update their code! This means the calling 
> code should fail to compile until it is updated.