4 ms·

I'm probably misunderstanding something here, but isn't the author's criticism of exception bubbling and duplicate code easily resolved with exception inheritan

I'm probably misunderstanding something here, but isn't the author's criticism of exception bubbling and duplicate code easily resolved with exception inheritance? Define a base exception that all others inherit from and catch that in the general case. If you want to take action when a particular exception occurs, add a catch block for it. Duplicate error handlers could be factored out into helpers.

ncmncm 4y ago
The author complains about his own misunderstanding of, and consequent misuse of exceptions. Put all your cleanup in destructors. All of it. They exercise that code all the time, on every run. Then, throwing always does the right thing, with no extra effort.
- JonChesterfield 4y ago
  Good thing cleanup code can never fail, what with there being no way to report failure from a destructor.
  - ncmncm 4y ago
    Destructors can log. Destructors can set flags.
    - dralley 4y ago
      At which point you're dealing with errno C error handling anyway.
benreesman 4y ago
C++ exceptions are considered by many a misfeature and that consensus seems to be growing. There are myriad corner cases with accidental slicing, pretty nasty performance failure modes, and toolchain/flag/platform quirks. You can do pretty OK Maybe/Either types in modern C++, but there’s not an obvious way to get the ergonomics you want. At the time this was written the right move was usually to signal failure with a return value and return your successful value with an out-parameter. Java can do exceptions with VM/JIT support and it’s much more predictable, but doesn’t hit large parts of the domain. Anything north of Java in runtime support is targeting non-overlapping domains to C++ in 2022. Rust is doing a somewhat exciting experiment with custom syntax for Maybe/Either. It’s a bit soon to say how it will age. I fear it won’t turn out to be general enough, but it beats the hell out of errno.

ncmncm 4y ago

The author complains about his own misunderstanding of, and consequent misuse of exceptions. Put all your cleanup in destructors. All of it. They exercise that code all the time, on every run. Then, throwing always does the right thing, with no extra effort.

JonChesterfield 4y ago
Good thing cleanup code can never fail, what with there being no way to report failure from a destructor.
- ncmncm 4y ago
  Destructors can log. Destructors can set flags.
  - dralley 4y ago
    At which point you're dealing with errno C error handling anyway.

benreesman 4y ago

C++ exceptions are considered by many a misfeature and that consensus seems to be growing. There are myriad corner cases with accidental slicing, pretty nasty performance failure modes, and toolchain/flag/platform quirks. You can do pretty OK Maybe/Either types in modern C++, but there’s not an obvious way to get the ergonomics you want. At the time this was written the right move was usually to signal failure with a return value and return your successful value with an out-parameter. Java can do exceptions with VM/JIT support and it’s much more predictable, but doesn’t hit large parts of the domain. Anything north of Java in runtime support is targeting non-overlapping domains to C++ in 2022. Rust is doing a somewhat exciting experiment with custom syntax for Maybe/Either. It’s a bit soon to say how it will age. I fear it won’t turn out to be general enough, but it beats the hell out of errno.