On Tuesday, 27 June 2017 at 21:47:49 UTC, jag wrote:
On Tuesday, 27 June 2017 at 19:37:24 UTC, Moritz Maxeiner wrote:
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).
Can I as a programmer who wants to call a function written by
someone else inspect the declaration of that function and know
what exceptions are possible?
* Can I as a programmer who wants to call a function written by
someone else inspect that function's exception set?
Yes, as explained fully here [1], shown as an idiomatic D trait
here [2], and a template based abstraction around that trait here
[3]. It would need to be implemented, of course, but it's not
conceptually hard.
If no how is this supposed to work?
It was explained multiple times in this thread.
I am supposed to specify that exceptions I want to allow the
called function to throw?
You aren't supposed to do anything, but you can do that, yes.
The called function is not going to dynamically adapt itself
and change the list of exceptions it throws, right?
What? A function's exception set is determined by its body and
can be aggregated by the compiler in a single recursive pass in
the static analysis phase.
So how can I know, before running the code, what exceptions are
possible?
You mean the very first time you want to call it and you don't
know the exception set yourself by looking at its signature?
Put the call in a nothrow scope and compile the module (which is
fast in D), the compiler will then complain which exceptions you
didn't catch (requires improvement of nothrow analysis [1]).
[1]
http://forum.dlang.org/post/[email protected]
[2]
http://forum.dlang.org/post/[email protected]
[3]
http://forum.dlang.org/post/[email protected]
