undefined | Better HN

0 pointsilammy4y ago0 comments

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.

0 comments

dataflow4y 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.

ilammyOP4y 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.

dataflow4y 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.

1 more reply

minipci13214y 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.)

j / k navigate · click thread line to collapse

0 pointsilammy4y ago0 comments

The point is, retrofitting exceptions onto existing codebase is a lot of pain.

0 comments

dataflow4y ago

Go try this with std::sort (or std::adjacent_find or whatever) and tell me which of their implementations you had to modify.

ilammyOP4y 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.

dataflow4y 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?

1 more reply

minipci13214y 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.)

j / k navigate · click thread line to collapse