Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

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 <moritz at ucworks.org>:
>
> 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.