On Tuesday, 27 June 2017 at 00:29:53 UTC, crimaniak wrote:
On Monday, 26 June 2017 at 19:31:53 UTC, Moritz Maxeiner wrote:
And the good *way* to achieve this result would be the
following:
- When visiting `startFoo`, the compiler automatically
aggregates all different exceptions it may throw and stores
the resulting set
- If `startFoo` is going to be part of a (binary) library and
its symbol is exported, also export its exception set
- Improve the compiler's nothrow analysis such that if
startFoo is called in scope S, but all of the exceptions in
its exception set are caught (i.e. can't break out of scope
S), it is treated as nothrow in S.
- Enclose the call to `startFoo` in B in a nothrow scope.
After preparing my message I read tail of the thread and see
your vision very close to mine. 👍
I wouldn't call it a vision, since I personally don't need it.
It's just that I consider checked exceptions as an excuse for not
improving a deficient compiler.
So listing exceptions that can be thrown is a good thing
because it helps you write more reliable code.
It is a bad thing because you force a human to do a machine's
job.
This is a bad necessity, but a necessary opportunity. Sometimes
you need to be sure that the compiler's vision matches yours.
I would need a concrete example that's not either solved by the
steps mentioned in my post, or using compile time introspection
on a function's exception set (as shown in John's idiomatic
proposal [1]).
[1]
http://forum.dlang.org/post/[email protected]
