5 ms·

Don't you need exceptions though? How do you terminate arbitrary operations without exceptions? Like say you call an algorithm (like std::sort) and during a ca

Don't you need exceptions though? How do you terminate arbitrary operations without exceptions? Like say you call an algorithm (like std::sort) and during a callback (e.g. in the comparator) you decide to cancel the operation (perhaps user-requested). With exceptions it's easy; you just throw an exception and then catch it. No need to touch or even know the intermediate callers. But without exceptions what do you do? You have to go modify or reimplement the source code of every intermediate function, which is a giant waste of effort at best, and in reality a likely vector for introducing code duplication, brittleness, and bugs.

ilammy 5y ago
But with exceptions what do you do? You have to go modify or reimplement the source code of every intermediate function to be correct and safe when an exception is thrown at every point where it can be thrown, which is a giant waste of effort at best, and in reality a likely vector for introducing code duplication, brittleness, and bugs. The point is, retrofitting exceptions onto existing codebase is a lot of pain. Interruptible functions have the API they have because they have been designed with exceptions in mind for interruptions. If there were no exceptions, the callbacks would have had a different API. A special return value could be used to signal an interruption.
- dataflow 5y ago
  No you don't, you're massively exaggerating. The standard library already has at least basic if not strong exception-safety all over it. And RAII is pretty darn standard practice and guarantees basic exception safety in your own code too. You don't need strong exception safety here, just basic is sufficient for most such cases. Go try this with std::sort (or std::adjacent_find or whatever) and tell me which of their implementations you had to modify.
  - ilammy 5y ago
    Well but of course! These functions are already implemented with basic exception safety in mind. What if they weren't? This is exactly the same situation as a function that has callback(); which cannot be changed into if Err(error) = callback() { return error; } because that would break some invariants. Changing return type from "void" into some "result" is a mechanical change.
    - dataflow 5y ago
      As I already explained: RAII is pretty darn standard practice and guarantees basic exception safety in your own code too. The music is already there and people are already dancing to it. > What if they weren't? Obviously the language wasn't designed for rebels. The implicit understanding with tools is that you use them the way they're meant to be used. Only in that case do you get to assume you'll reap the benefits they claim to provide. If you insist on deliberately dancing to a different tune, then you get exactly what you asked for. You can't drive against traffic and then complain people run into you.
      - hyperman1 5y ago
        There are interesting non-rebel cases of What if they weren't. I have a library (object only, no source) written for C (not C++) which wants callbacks. It is the only interface provided by the vendor for something that shall remain nameless. Every callback has to be wrapped in a try catch, or hell will break loose.
    - minipci1321 5y ago
      > Changing return type from "void" into some "result" is a mechanical change. .. but then checking the returned val for error in every call sites is very far from mechanical change. (Attribute about unused return result can help here, with obvious drawbacks.)
deleted 5y ago
[deleted]
ribit 5y ago
I agree that a modern high-level programming language model needs an ergonomic error model. But C++ exceptions are not the only way to go. You can have error model that have similar (or even better ergonomy) than C++ while not having any of the drawbacks (like extremely complicated runtime stack, slow exception handling, messed up control flow etc.). Basically, in my personal opinion, any error handling that involves automatic stack unwinding is a failure.
- dataflow 5y ago
  Note you didn't really answer my question at all. Right now lots of algorithms like std::search, std::find_if, etc. are not only exception-safe, but in fact exception-agnostic. Neither the algorithm, nor you, need to know a priori if your predicates will throw exceptions (which are things that may be literally impossible to know upfront), and yet despite that, (a) the algorithms will work completely correctly if any exception is thrown, (b) if you do need to do something like canceling the operations in the middle, you have a means to do that via exceptions, and (c) you will get extremely high performance as long as you don't throw an exception. That's a lot of flexibility even the most trivial implementations of many such algorithms get absolutely for free. (!) I don't know about you, but to me the fact that I can suddenly decide to "cancel" many functions halfway despite their authors never having to even think about that possibility is pure awesomeness. So I asked "how would you do achieve {the benefits of the exception model} without exceptions" but you just said "it is possible" and... left me hanging. Well if that's really true, then how? > You can have error model that have similar (or even better ergonomy) than C++ while not having any of the drawbacks I don't buy it. Unless you're intentionally allowing yourself to introduce drawbacks that never existed in C++'s model. If you're really saying you can find a strictly better solution, then we're all definitely interested in hearing... and I'll believe it when I see it. You have to realize ergonomicity (word?) isn't the only axis here. Performance is also a big one, and C++ is designed for maximizing performance in non-exceptional executions. I don't know what error models you're thinking of, but anything along the obvious stuff I've seen (like the usual "replace T with maybe<T>/optional<T>/fancy<T>") would come with far greater performance hits even in the 'happy' paths than C++ has (not to mention potential increases in memory usage, etc. in more complex cases), and even their ergonomics would be debatable depending on the situation.

ilammy 5y ago

But with exceptions what do you do? You have to go modify or reimplement the source code of every intermediate function to be correct and safe when an exception is thrown at every point where it can be thrown, which is a giant waste of effort at best, and in reality a likely vector for introducing code duplication, brittleness, and bugs. The point is, retrofitting exceptions onto existing codebase is a lot of pain. Interruptible functions have the API they have because they have been designed with exceptions in mind for interruptions. If there were no exceptions, the callbacks would have had a different API. A special return value could be used to signal an interruption.

dataflow 5y ago
No you don't, you're massively exaggerating. The standard library already has at least basic if not strong exception-safety all over it. And RAII is pretty darn standard practice and guarantees basic exception safety in your own code too. You don't need strong exception safety here, just basic is sufficient for most such cases. Go try this with std::sort (or std::adjacent_find or whatever) and tell me which of their implementations you had to modify.
- ilammy 5y ago
  Well but of course! These functions are already implemented with basic exception safety in mind. What if they weren't? This is exactly the same situation as a function that has callback(); which cannot be changed into if Err(error) = callback() { return error; } because that would break some invariants. Changing return type from "void" into some "result" is a mechanical change.
  - dataflow 5y ago
    As I already explained: RAII is pretty darn standard practice and guarantees basic exception safety in your own code too. The music is already there and people are already dancing to it. > What if they weren't? Obviously the language wasn't designed for rebels. The implicit understanding with tools is that you use them the way they're meant to be used. Only in that case do you get to assume you'll reap the benefits they claim to provide. If you insist on deliberately dancing to a different tune, then you get exactly what you asked for. You can't drive against traffic and then complain people run into you.
    - hyperman1 5y ago
      There are interesting non-rebel cases of What if they weren't. I have a library (object only, no source) written for C (not C++) which wants callbacks. It is the only interface provided by the vendor for something that shall remain nameless. Every callback has to be wrapped in a try catch, or hell will break loose.
  - minipci1321 5y ago
    > Changing return type from "void" into some "result" is a mechanical change. .. but then checking the returned val for error in every call sites is very far from mechanical change. (Attribute about unused return result can help here, with obvious drawbacks.)

deleted 5y ago

[deleted]

ribit 5y ago

I agree that a modern high-level programming language model needs an ergonomic error model. But C++ exceptions are not the only way to go. You can have error model that have similar (or even better ergonomy) than C++ while not having any of the drawbacks (like extremely complicated runtime stack, slow exception handling, messed up control flow etc.). Basically, in my personal opinion, any error handling that involves automatic stack unwinding is a failure.

dataflow 5y ago
Note you didn't really answer my question at all. Right now lots of algorithms like std::search, std::find_if, etc. are not only exception-safe, but in fact exception-agnostic. Neither the algorithm, nor you, need to know a priori if your predicates will throw exceptions (which are things that may be literally impossible to know upfront), and yet despite that, (a) the algorithms will work completely correctly if any exception is thrown, (b) if you do need to do something like canceling the operations in the middle, you have a means to do that via exceptions, and (c) you will get extremely high performance as long as you don't throw an exception. That's a lot of flexibility even the most trivial implementations of many such algorithms get absolutely for free. (!) I don't know about you, but to me the fact that I can suddenly decide to "cancel" many functions halfway despite their authors never having to even think about that possibility is pure awesomeness. So I asked "how would you do achieve {the benefits of the exception model} without exceptions" but you just said "it is possible" and... left me hanging. Well if that's really true, then how? > You can have error model that have similar (or even better ergonomy) than C++ while not having any of the drawbacks I don't buy it. Unless you're intentionally allowing yourself to introduce drawbacks that never existed in C++'s model. If you're really saying you can find a strictly better solution, then we're all definitely interested in hearing... and I'll believe it when I see it. You have to realize ergonomicity (word?) isn't the only axis here. Performance is also a big one, and C++ is designed for maximizing performance in non-exceptional executions. I don't know what error models you're thinking of, but anything along the obvious stuff I've seen (like the usual "replace T with maybe<T>/optional<T>/fancy<T>") would come with far greater performance hits even in the 'happy' paths than C++ has (not to mention potential increases in memory usage, etc. in more complex cases), and even their ergonomics would be debatable depending on the situation.