Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 16:01:37 UTC, mckoder wrote:
> On Tuesday, 27 June 2017 at 11:40:02 UTC, Moritz Maxeiner wrote:
>>>
>>> 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).
>
> You might as well argue that you shouldn't have to declare the 
> return type of functions because the compiler can determine 
> that automatically based on the types of values you are 
> actually returning.

Of *course* you shouldn't have to (-> auto functions [1]).
The difference being, of course, that specifying the return type 
is always only a single type, whereas specifying the exception 
set blows up in verbosity with each additional level of call 
hierarchy.

> Then write unit tests to make sure that the return type as 
> determined by the compiler matches what you intended.

If you don't trust the compiler's return type inference you can 
do that, of course.
Though in contrast to the exception set there's a lot less reason 
to do so in the return type case, because it's only a single type 
not an arbitrarily large set of types.

[1] https://dlang.org/spec/function.html#auto-functions