On Tuesday, 27 June 2017 at 06:10:52 UTC, Tobias Müller wrote:
Moritz Maxeiner <[email protected]> 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.
