On Friday, 7 July 2017 at 18:48:31 UTC, Marco Leise wrote:
Am Thu, 06 Jul 2017 13:16:23 +0000
schrieb Moritz Maxeiner <[email protected]>:
That's right, but still one can distill general ideas and leave
implementations details aside. Pretty much like the Platonic
Ideal. Then you look at what the complaints are with the
current implementation and see if you can satisfy all sides.
The requirement checked exceptions impose on all functions to
declare their respective exception set is not an implementation
detail, but part of the definition.
With regards to the general ideas: That's what my writing about
exception sets, tehir inference, and nothrow analysis were
(supposed to be) about.
Unless, however, whatever one eventually tries to get into the
language (if that is even attempted) conforms to the preexisting
definition of checked exceptions (which I'm as certain as I can
reasonably be won't make it into D), calling it that will only
serve to cloud the issue and alienate people.
Personally, I would call a system with the exception set of a
function being (optionally) declarable as "declarable
exceptions", but that might still be too close to "checked
exceptions" not to illicit screams of horror.
[...]
I.e. everything stays the same until a programmer needs a
verification of what (s)he should/could handle right away, what
needs to be wrapped and what can be passed further up the call
chain. That's close to impossible now in deeply nested code.
If one replaces the `@check_exceptions` with `nothrow` the above
is essentially what one should get if one enhances the (static)
nothrow analysis (as I mentioned in an earlier post) to
essentially treat a scope implicitly as nothrow if the aggregated
exception set (as determined by the compiler) is empty.
Or more succinct: Infer `nothrow` for normal functions, as well.
In other cases an exception is only thrown when an incorrect
argument is passed. Knowing (statically) that you pass only
good values you can catch the exception and turn it into an
assert instead of passing it up the call chain, potentially
allowing the caller to be nothrow.
There are two cases here:
- the function takes untrusted user data:
Violations are valid runtime behaviour -> Exceptions, error
codes, split in validation and processing function pair with the
second being executed only after the first has successfully
validated the input data (and thus transformed it into trusted
program data), etc.
- the function takes trusted program data:
Violations are bugs -> assert, Error, DbC, etc.
