Checked vs unchecked exceptions

mckoder via Digitalmars-d digitalmars-d at puremagic.com
Sun Jun 25 10:38:14 PDT 2017


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.


More information about the Digitalmars-d mailing list