Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 18:14:47 UTC, jag wrote:
> As Tobias mentioned, there are safety implications to "auto" 
> behavior. In the example below I am using C# and its "var" 
> feature:
>
> [...]

Your example uses variable type inference, which happens on the 
*caller* side, *not* the *callee* side, the latter of which being 
where both checked exceptions and return type inference happen.
The correct analogue to your example in the exception domain is 
thus *not* checked exceptions, but verifying the exception set 
*at the call site* (the same way you fix the variable type *at 
the call site* to `Employee`), which is exactly what you can do 
by exposing the function exception set via a trait.

> Now the compiler is able to catch your mistake. This is the 
> reason your code becomes safer when you express your intent 
> clearly. You should have the option to state your intent 
> clearly by listing the exceptions that can be thrown by a 
> method.

As I have pointed out, your example occurs on the *caller* side, 
not the *callee* side. The proper solution is not for the callee 
to specify which exceptions it may throw, but for the caller to 
specify which exceptions it allows the callee to throw (using 
compile time introspection on the exception set).

> In dynamic languages like Python [...]

None of this justifies putting the burden on the callee side 
(i.e. checked exceptions), instead of on the caller side (the 
latter being implementable in an idiomatic way using a trait as 
John has proposed).