> Quite honestly knowing that a function “throws” but not
> *what* it throws, is useless.
>
> Now if it were a proposal to add *runtime checked*
> `throws FooException, BarTypeError` or similar, I could get behind.
>
Agreed.  I use noexcept in C++ *because* it adds value.  If this proposal
were along the lines of the following (with runtime checking included),
then I could get on board:

1) function foo(): type noexcept {...}
and/or
2) function foo(): type throws(Type) {...}

I don't even expect the runtime checks would hurt the happy path much since
we already have a check for active exceptions during the function unwind,
and once we know we have an exception, we're in the sad path and an extra
millisecond to check the exception type isn't going to break the bank.

I would say that any exception thrown in (1) should lead to an non-zero
exit since the program has violated an invariant assumption. Similarly if
an exception which is not of type "Type" in (2) should do the same.  2
should (arguably) allow for union typing the way catch does.  (e.g.
 throws(Foo | Bar | Baz)

Basically, the problem with this proposal IMO is that it doesn't go nearly
far enough, and that a single character modifier is unhelpful compared to
something actually readable.

-Sara

Reply via email to