4 ms·

They're zero(ish) cost at runtime, but focusing on just that is missing something: pervasive unchecked exceptions inhibit optimisations, both in compilers and i

by dbaupp 9y ago

They're zero(ish) cost at runtime, but focusing on just that is missing something: pervasive unchecked exceptions inhibit optimisations, both in compilers and in libraries, which have to be more defensive to preserve correctness.

searealist 9y ago
I guess that's why you Rust guys don't have exceptions, so you don't have to pay this cost. </s>
- dbaupp 9y ago
  (Explanation of the /s: panics use the same mechanism, so the compiler and libraries unfortunately still have to be just as defensive when they're enabled. When the compiler is in -C panic=abort mode, it doesn't suffer from this, but I don't think libraries have a great way to customise/improve their behaviour in that case at the moment.)
int_19h 9y ago
If you replace exceptions with e.g. return values, it doesn't really change anything for the libraries - if they expect to be able to deal with an error, they still have to defensively preserve correctness. OTOH the library always has the option to say "this particular thing that you give me should be nothrow; if it throws, that's U.B.", and not even try being defensive in the face of exceptions when they come out of such a thing.
- milesrout 9y ago
  The thing is, in C++ you have to explicitly write noexcept for that to happen. If you use optional<T> you have to explicitly write that, and turning off exceptions means you don't have to write noexcept everywhere.
- dbaupp 9y ago
  I think you missed the precise qualification of my comment: this only applies when the compiler can't tell what exceptions can occur, like in C++, Rust and even Java, and so needs to be able to handle any/all of them. The most basic (and most relevant) query is "can this call throw?", but even that is impossible to answer without global information when there are unchecked exceptions. In statically typed languages, return values, like (fully) checked exceptions, are different, as they're exactly the sort of global information the compiler needs. Functions can statically guarantee the exact set of ways in which it can interact with its caller, and the compiler can understand. This means a function that, say, sorts a list with a less-than function (that returns bool) knows that every time that function exits, it gives a value of true or false, no exceptions (hah). In any case, just writing a library that says "UB to throw" isn't quite enough, as the compiler won't understand, and will still structure code to handle exceptions "sensibly", even thought it doesn't need to. Fixing that means being able to communicate nothrow to the compiler (which is nice too), but this starts to no longer be a pervasive unchecked error system: it's somewhat of a binary form of checking.
  - int_19h 9y ago
    Well, we were talking about exceptions in C++, where there is a standard way to communicate nothrow. So yes, you're right that it's no longer a pervasively unchecked error system - but that's precisely why they're not any worse than Result<T,E> at this point. Effectively you can treat C++ as having every function return Result<T,E> by default, with nothrow being an opt-out to just return T.

by dbaupp 9y ago

searealist 9y ago

I guess that's why you Rust guys don't have exceptions, so you don't have to pay this cost. </s>

dbaupp 9y ago
(Explanation of the /s: panics use the same mechanism, so the compiler and libraries unfortunately still have to be just as defensive when they're enabled. When the compiler is in -C panic=abort mode, it doesn't suffer from this, but I don't think libraries have a great way to customise/improve their behaviour in that case at the moment.)

int_19h 9y ago

If you replace exceptions with e.g. return values, it doesn't really change anything for the libraries - if they expect to be able to deal with an error, they still have to defensively preserve correctness. OTOH the library always has the option to say "this particular thing that you give me should be nothrow; if it throws, that's U.B.", and not even try being defensive in the face of exceptions when they come out of such a thing.

milesrout 9y ago
The thing is, in C++ you have to explicitly write noexcept for that to happen. If you use optional<T> you have to explicitly write that, and turning off exceptions means you don't have to write noexcept everywhere.
dbaupp 9y ago
I think you missed the precise qualification of my comment: this only applies when the compiler can't tell what exceptions can occur, like in C++, Rust and even Java, and so needs to be able to handle any/all of them. The most basic (and most relevant) query is "can this call throw?", but even that is impossible to answer without global information when there are unchecked exceptions. In statically typed languages, return values, like (fully) checked exceptions, are different, as they're exactly the sort of global information the compiler needs. Functions can statically guarantee the exact set of ways in which it can interact with its caller, and the compiler can understand. This means a function that, say, sorts a list with a less-than function (that returns bool) knows that every time that function exits, it gives a value of true or false, no exceptions (hah). In any case, just writing a library that says "UB to throw" isn't quite enough, as the compiler won't understand, and will still structure code to handle exceptions "sensibly", even thought it doesn't need to. Fixing that means being able to communicate nothrow to the compiler (which is nice too), but this starts to no longer be a pervasive unchecked error system: it's somewhat of a binary form of checking.
- int_19h 9y ago
  Well, we were talking about exceptions in C++, where there is a standard way to communicate nothrow. So yes, you're right that it's no longer a pervasively unchecked error system - but that's precisely why they're not any worse than Result<T,E> at this point. Effectively you can treat C++ as having every function return Result<T,E> by default, with nothrow being an opt-out to just return T.