4 ms·

> No they don't. An exception that isn't thrown costs nothing. Wait whaaat? When every expression can throw anything, the compiler and the user both loose the

> No they don't. An exception that isn't thrown costs nothing. Wait whaaat? When every expression can throw anything, the compiler and the user both loose the ability to reason about code locally. They change any function from returning one value of one type, to returning any value of any type. This: - has a performance cost: it breaks lots of compiler optimizations that require knowing where and what can functions return. - has a compile-time cost: compiler needs to generate code for landing pads all over the place, this code must be optimized, etc. - has a code-size cost: the landing pads must be generated in the binary, - has a usability cost: users can't reason about their programs if they can't reason about where functions can return and what they can return - has a teachability cost: users have to be taught _a lot_ about how to use exceptions properly because of their cost. Herb Sutter has a whole damn series of books, a series of damn books, about how to use exceptions properly and avoid their pitfalls. When you need a series of books to explain 1 single feature of your programming language, that feature is _wrong_. And writing and reading these books has a huge cost. Exceptions are as free as Google or Facebook. You can use them for free as long as you gift them your soul so that they can sell it for profit.

jcelerier 5y ago
it's obvious that OP meant a performance cost - as generally when you program in C++ that's the n°1 metric. And for that one, exceptions as they are today are often faster than the equivalent error-code-based code: https://nibblestew.blogspot.com/2017/01/measuring-execution-performance-of-c.html https://nibblestew.blogspot.com/2017/01/measuring-execution-... Of course if we can get even faster exceptions such as the throwing values model, by all means let's do it... i'm entirely fine with recompiling literally every software / library I use if that can get me half a % more performance
- ggreg84 5y ago
  > And for that one, exceptions as they are today are often faster than the equivalent error-code-based code: https://nibblestew.blogspot.com/2017/01/measuring-execution- https://nibblestew.blogspot.com/2017/01/measuring-execution-... The example on that blog post is not representative of how error codes are used. On all programming languages, C included, but also Rust, functions return a completion value that's either success, or error (and when its error, it includes which error it is, and the error state, etc.). int foo(); switch (foo()) case 0: break; // success case 1: /* error case 1 */ case 2: /* error case 2 */ ... Instead, the blog post has the function return some value in registers that is not an error, and passes the function an ErrorState* as an argument, that the function first sets via memory, and then the handler reads, also via memory. That this is slow is not rocket science, which is why nobody does this. I get why the author has to do it. If they were to do it right, error codes would perform significantly better than exceptions. Since returning the error or success is "free" (the function has to return anyways, and up to 2 registers are reserved by the ABI anyways). Somebody mentions this in the comments, were as far as fixing it and sending a PR (https://github.com/jpakkane/excspeed/pull/1 https://github.com/jpakkane/excspeed/pull/1) but the author complains that this is not how GLib does error codes, so they don't care. So yeah, if you do C error codes like GLib does, which is essentially a poor man's emulation of exceptions, then sure, exceptions are faster than doing error codes wrong. Most people using C do it right, and so does Rust's Result (and all Rust programs).

jcelerier 5y ago

it's obvious that OP meant a performance cost - as generally when you program in C++ that's the n°1 metric. And for that one, exceptions as they are today are often faster than the equivalent error-code-based code: https://nibblestew.blogspot.com/2017/01/measuring-execution-performance-of-c.html https://nibblestew.blogspot.com/2017/01/measuring-execution-... Of course if we can get even faster exceptions such as the throwing values model, by all means let's do it... i'm entirely fine with recompiling literally every software / library I use if that can get me half a % more performance

ggreg84 5y ago
> And for that one, exceptions as they are today are often faster than the equivalent error-code-based code: https://nibblestew.blogspot.com/2017/01/measuring-execution- https://nibblestew.blogspot.com/2017/01/measuring-execution-... The example on that blog post is not representative of how error codes are used. On all programming languages, C included, but also Rust, functions return a completion value that's either success, or error (and when its error, it includes which error it is, and the error state, etc.). int foo(); switch (foo()) case 0: break; // success case 1: /* error case 1 */ case 2: /* error case 2 */ ... Instead, the blog post has the function return some value in registers that is not an error, and passes the function an ErrorState* as an argument, that the function first sets via memory, and then the handler reads, also via memory. That this is slow is not rocket science, which is why nobody does this. I get why the author has to do it. If they were to do it right, error codes would perform significantly better than exceptions. Since returning the error or success is "free" (the function has to return anyways, and up to 2 registers are reserved by the ABI anyways). Somebody mentions this in the comments, were as far as fixing it and sending a PR (https://github.com/jpakkane/excspeed/pull/1 https://github.com/jpakkane/excspeed/pull/1) but the author complains that this is not how GLib does error codes, so they don't care. So yeah, if you do C error codes like GLib does, which is essentially a poor man's emulation of exceptions, then sure, exceptions are faster than doing error codes wrong. Most people using C do it right, and so does Rust's Result (and all Rust programs).