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).
