5 ms·

When a database transaction fails, it rolls back to the state before the transaction. Exceptions ought to work like this too. Then you wouldn’t have to think a

by panic 8y ago

When a database transaction fails, it rolls back to the state before the transaction. Exceptions ought to work like this too. Then you wouldn’t have to think about all the places an exception could be thrown. A try-catch block would either completely succeed, following the well-tested success path, or completely fail, leaving the program in its original state.

gpderetta 8y ago
In C++ there is a thing called exception safety and there are three level: * No throw: the function will not fail. Full stop. * Strong exception safety: if the function fails the state of the object(s) is acting on is unchanged. This is similar to transactional atomicity guarantee. * Basic guarantee. If the function fails the state of the objects is unspecified but valid (i.e. no invariant is violated), but data might be lost. From the point of view of the caller of course no throw is the most desirable property, the strong and finally basic. Anything less than that (i.e. corruption, leaks, dangling pointers) is considered unacceptable. Another important insight is realising that exception guarantees have little to do with exceptions and everything to do with postconditions in the return path: for example the same techniques used to guarantee strong safety on the face of exceptions also work to guarantee postconditions on the faceof multiple explicit retun paths.
- mcguire 8y ago
  Transactions and strong exception safety have two things in common: they're easy to use and hard to implement.
  - gpderetta 8y ago
    You are correct, but fully transactional semanatics by default would be extremely hard to do on a non gc-ed system language like C++. I could definitely see a language with such a feature though (transactional memory would be a good place to start I guess).
dllthomas 8y ago
You can't un-fire the missiles. This might be a great approach for some (plausibly very large) subset of cases, but it can't handle everything.
- aaron_m04 8y ago
  > You can't un-fire the missiles. True, but you can always offer at least the basic guarantee, and you can always document what you are guaranteeing to the caller.
- gpderetta 8y ago
  You can wait to fire them until commit time though. Also abort sequences are a thing so you can kinda-sorta unfire them (talk about compensating sequence!).
  - dllthomas 8y ago
    > You can wait to fire them until commit time though. Not in a way that truly solves the problem. Any time you are coordinating multiple actions that are irreversible and may fail, you'll need some contract other than "either your transaction exceeds or everything is rolled back."

by panic 8y ago

gpderetta 8y ago

In C++ there is a thing called exception safety and there are three level: * No throw: the function will not fail. Full stop. * Strong exception safety: if the function fails the state of the object(s) is acting on is unchanged. This is similar to transactional atomicity guarantee. * Basic guarantee. If the function fails the state of the objects is unspecified but valid (i.e. no invariant is violated), but data might be lost. From the point of view of the caller of course no throw is the most desirable property, the strong and finally basic. Anything less than that (i.e. corruption, leaks, dangling pointers) is considered unacceptable. Another important insight is realising that exception guarantees have little to do with exceptions and everything to do with postconditions in the return path: for example the same techniques used to guarantee strong safety on the face of exceptions also work to guarantee postconditions on the faceof multiple explicit retun paths.

mcguire 8y ago
Transactions and strong exception safety have two things in common: they're easy to use and hard to implement.
- gpderetta 8y ago
  You are correct, but fully transactional semanatics by default would be extremely hard to do on a non gc-ed system language like C++. I could definitely see a language with such a feature though (transactional memory would be a good place to start I guess).

dllthomas 8y ago

You can't un-fire the missiles. This might be a great approach for some (plausibly very large) subset of cases, but it can't handle everything.

aaron_m04 8y ago
> You can't un-fire the missiles. True, but you can always offer at least the basic guarantee, and you can always document what you are guaranteeing to the caller.
gpderetta 8y ago
You can wait to fire them until commit time though. Also abort sequences are a thing so you can kinda-sorta unfire them (talk about compensating sequence!).
- dllthomas 8y ago
  > You can wait to fire them until commit time though. Not in a way that truly solves the problem. Any time you are coordinating multiple actions that are irreversible and may fail, you'll need some contract other than "either your transaction exceeds or everything is rolled back."