3 ms·
My biggest beef with exceptions is invisible code flow. Add the attribute throws<t> to function signature (so that its visible) and enforce handling by generati
by smallstepforman 11mo ago
My biggest beef with exceptions is invisible code flow. Add the attribute throws<t> to function signature (so that its visible) and enforce handling by generating compiler error if ignored. Bubbling up errors is OK. In essence, this is result<t,e>. Thats OK. Even for constructors.
What I dislike is having a mechanism to skip 10 layers of bubbling deep inside call stack by a “mega” throw of type <n> which none of the layers know about. Other than
- gpderetta 11mo agoI would also like to have type checked exceptions in c++ (as long as we can also template over exception specifications). But what I would really want is noexcept regions: <potentially throwing code>... noexcept { <only noexcept code here> ... } <potentially more throwing code>... i.e. a way to mark regions of code that cannot deal with unwind and must only call non-throwing operations.
- wakawaka28 11mo agoDon't think of the uncaught type as a "mega" throw. It's just a distinct type of error that nobody specified that they can handle. If you truly worry about the caller missing something, then somewhere in there you can catch anything and translate into a recognizable exception. This is easiest to understand in a library. The interface functions can catch all and translate into one particular exception type for "unknown" or generic errors. Then, that will be caught by anyone using the thing as documented. This only works if it's just reporting a non-fatal error. In case of a fatal error, it can't be handled, so the translation is kind of pointless.