Feature Request: gsl::finally.ignore()

[rianquinn]

C++ exceptions are amazing, but they introduce an issue with how to handle state. The commit / rollback pattern is amazing at handling this:

http://stackoverflow.com/questions/10983791/c-transaction-like-pattern-for-all-or-nothing-work

Basically, it allows you to do the following:

auto cor1 = CommitOrRollback([]{
    undo action1
});

action1();

auto cor2 = CommitOrRollback([]{
    undo action2
});

action2();

cor1.commit();
cor2.commit();

gsl::finally is exactly the same thing, but is missing the "commit" function. Since the "finally" operation is sort of backwards, I propose calling it "ignore" and can be implemented doing the following (tested and already working in our repo).

void ignore() noexcept { invoke_ = false; }

This added API would not affect how it is currently used, but would add the ability to prevent the action from executing based on a condition, which means it would be able to be used for rolling back state in the event of an exception, something that IMO should be integral to the C++ stack.

Also on the GSL tracker:
microsoft/GSL#335 (comment)

[MikeGitb]

Personally I'd rather call it dismiss, but I think the feature would indeed be useful. It might be interesting to see if this has any significant influence on the codegen when it is not used.

[galik]

But... if there are parts of the code that require you to call ignore() have you not sort of just re-introduced the kind of problem that finally was created to solve? What if you forget to call ignore()?

[rianquinn]

@galik What if you forget to write the finally in the first place? All we are doing here is adding an additional capability to finally so that it can be used for the commit / rollback pattern that addresses a pretty significant issue with C++ exceptions.

[rianquinn]

@MikeGitb I dismiss too.

[BjarneStroustrup]

finally() does exactly what it is intended to do: install an operation to be executed at the end of scope. It is less disciplined than an object with a more specific destructor, but it can be used to implement a commit. A major advantage of destructors and RAII is that the remove the opportunity to forget to clean up a constructed object. Having explicit close, dispose, release, commit, unlock, etc. actions is an opportunity to forget, to get bugs.

[rianquinn]

What about adding another class to the GSL that is a more traditional "commit or rollback"? Rolling back state changes in the event of an exception is a HUGE issue with C++ exceptions and using RAII is one of the best ways to deal with this issue (the alternative is to try, catch, rethrow, which is far more likely to introduce bugs).

A great example of this is the fact that we state with the STL to only use mutex lockers. One of the reasons for this is in the event of an exception, the locker will unlock the mutex preventing deadlock. Nothing exists in the STL or GSL to provide a means to rollback state as state changes are being made to a class.

[BjarneStroustrup]

How does what you suggest differ from, say std::lock_guard?

[rianquinn]

It doesn't minus it takes a lambda function instead of a mutex.

[Pazns]

Shouldn't we encase the state transaction in a one-purpose dedicated class and use it as RAII, instead of a generic lambda holder ?
Lambdas always feel a bit spaghettic to me.