
C++: RAII without exceptions - ingve
http://eli.thegreenplace.net/2016/c-raii-without-exceptions/
======
readams
I've never heard the claim that RAII requires exceptions, and the article
seems to do nothing to justify why anyone would think that. The opposite is
true in that RAII makes handling exceptions correctly far easier than it would
otherwise be.

But I'm wracking my brain trying to think why anyone would think that
exceptions are needed for RAII and am unable to come up with anything.

~~~
corysama
How do you externally detect and handle an error in a destructor? That's a
rather unusual and difficult case. But, it's still a legit concern. More
common and a bit easier (but still can be awkward) is handling errors in RAII
constructors.

I like RAII, but I haven't used it significantly. Meanwhile, I'm not a fan of
exceptions. So, how people make the two work together smoothly is an
interesting topic for me...

~~~
blt
I recall a C++ book saying something like "ignore it, log an error, or call
exit()" to handle an error in a destructor. In other words, there is no
correct answer. In practice, the operations usually performed in a destructor
are unlikely to fail, and in "typical" programs one of those 3 solutions is
probably acceptable. But it's a serious issue in software that is supposed to
be 100% robust, i.e. [1].

[1] [http://250bpm.com/blog:4](http://250bpm.com/blog:4)

------
wvenable
I do some embedded development in C++11 with exceptions disabled (for
size/compatibility) and using RAII to the fullest. It's all very smooth and
works very well.

~~~
corysama
Bendersky explicitly put off error handling for a later post. But, that's the
interesting part by far.

How does your team smooth out handling errors in RAII without exceptions?

~~~
wvenable
You can simply return error values either as a tuple, an error code, etc.
RAII, of course, takes care of the cleanup either way.

------
z92
This is the first time I have heard "RAII requires exception".

But then reading the comments section, I get that the author completely missed
the point.

The claimers, whoever they are, aren't claiming RAII needs exception for
deallocation, which the author has covered.

But they claim RAII needs exception to handle resource allocation failures.
Which the author is trying to undermine saying that is a rare case. Which
probably isn't that rare.

------
chillaxtian
the meat of the article:

"Another strong link between exceptions and RAII is in constructors.
Constructors cannot have return values. Therefore, if a constructor encounters
an error condition, you either throw an exception or mark some internal error
state. The latter has its issues (which is why alternative methods of
construction are recommended in code without exceptions), so throwing an
exception is the most common approach."

wish the author had provided examples of the alternative methods of
construction, rather than explain RAII from scratch.

~~~
sseagull
The only pattern I can think of is to construct via a free function. The free
function would call the real (basically empty) constructor, and then fill it
in via other member functions or by directly accessing the data (via
friendship). This free function would be able to allocate memory, etc, and
return error flags.

You could even make the real constructor private, which would prevent
inadvertently creating an object with an invalid state.

(Could also be done with a static member function, I suppose)

~~~
gpderetta
Yes, a free or static member function that returns an Either-like object is
the way to maintain strong RAII invariants while avoiding exceptions. Either,
named Result, has been proposed of the next standard.

Unfortunately C++ still doesn't have good facilities for dealing with monads
(i.e. do notation) making working with Either (and futures, and optionals)
quite awkward.

