http://forum.dlang.org/post/[email protected]
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.
