Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 06:10:52 UTC, Tobias Müller wrote:
> Moritz Maxeiner <moritz at ucworks.org> wrote:
>> [...]
>> Or, more succinct: You must either manually write things down 
>> the
>> compiler could find out in a fraction of the time via static
>> analysis, or cheat the system; both cases are bad code.
>
> It's not at all bad code to write things down that the compiler 
> could
> infer, quite the opposite.

Of course it is bad, because the compiler can do it better (no 
chance for a wrong exception set sans compiler bugs) and faster 
than you.

> Writing it down signals _intent_ and the compiler can check if 
> the implementation is matching the specification

Verifying that a function meets its specification is what 
unittests are for (asserts for runtime behaviour, static asserts 
for types).
With a function set trait there's nothing stopping you from 
writing a template that allows you to do the following:

---
void foo() { ... }

unittest
{
     static assert (throws!(foo, AException));
     static assert (throwsAll!(foo, AException, BException));
     static assert (throwsAny!(foo, AException, CException));
     static assert (!throws!(foo, CException));
}
---

which would be idiomatic D, giving you not only the same 
guarantees as checked exceptions (without the downsides), but 
also even more versatility by allowing arbitrary checks on the 
exception set.

> which gives you additional security.

This has nothing to do with security; you may be thinking of 
safety.

> Additionally it allowes the compiler to do the checks locally 
> which is much
> easier.

Easier to implement in the compiler, yes. That's precisely why I 
called it a compiler deficiency compared to exposing the function 
exception set, which is more advanced.

> Function signatures are interfaces which should be 
> self-contained IMO, i.e. it should not be necessary to examine 
> the function body.
> That's what signatures are for. At very least for public 
> interfaces.

Sure, but since a function's signature in D does not include its 
exception set (be they checked or not), that point is moot.

> I honestly don't understand how people that care a great deal 
> about expressive type systems can be so opposed to checked 
> exceptions. After all they wouldn't use 'object' for everything 
> either.

For exactly the reasons I have already explained.