Tonight: Introduction to D at Codeaholics (HK)

[Marco Leise via Digitalmars-d-announce]

Am Thu, 12 Nov 2015 01:30:06 +0800
schrieb Lionello Lunesu <lionello at lunesu.remove.com>:

> * Why doesn't D explicitly specify the exceptions that can be thrown? 
> (To which I answered that I never saw the point in Java and only found 
> it tedious. This did not convince the person.)

Maybe that's your point of view or maybe you were just
undecided. When you write a library it is sometimes better to
be explicit about your interface and that includes any
exceptions. This not only enables users of the library to
selectively catch exceptions they can handle at layer X, but
facilitates static checks:

* Are any exceptions missing from DDoc/@throws that are
  thrown in the code? (Potential for auto-generating the DDoc.)
* A function is nothrow, but the user only catches, e.g.
  UtfException explicitly. Is that the only exception type
  that could occur?

There were some more nice points that I don't remember from
when I failed at implementing this many months ago. The
questioner has my sympathy in any case, but it's certainly not
a priority.

The way I wanted to implement it was by making attribute-less
functions map to @throws(Exception), which implicitly makes
the feature opt-in: It is always correct to state a super set
of the actual thrown exceptions in an API to have room for
extensions. Thrown exceptions would be collected much like
nothrow is deduced right now, but as a list with respect to the
hierarchical nature of Exceptions.

-- 
Marco