
Use Noexcept for Exception Handling in C++ Programs - keyboardman
https://leimao.github.io/blog/noexcept-Specifier-CPP/
======
bastih
> The noexcept specifier protects C++ program from memory leaks and
> potentially other undesired behaviors brought by throwing exceptions.

While I agree with the presented observation, just letting the exception
bubble up to the top would have done the same thing. The memory leak presented
here is just the result of not using RAII to clean up the resource.

Throwing an exception through a `noexcept` function terminates (or rather
calls std::terminate) because you are doing something you explicitly said you
wouldn't do, pass an exception through this function.

> For key functions we hardly know how to handle its exceptions, it might be a
> good idea to add the noexcept specifier.

On the contrary, `noexcept`s usecase is in places where we want to be sure a
function doesn't just throw an exception, as this may thwart some guarantees
we want to make to the caller. Sprinkling your functions with `noexcept` just
to abort (which is already happening if the exception is unhandled) is bad
code. Plus "we hardly know how to handle its exceptions" is the worst cop-out
I've heard for dealing with exceptions - C++ exceptions are an essential part
of the language and many libraries, so dealing with them should be a prime
concern of the programmer.

~~~
yati
I agree with your pointa. A note though, I also used to think exceptions are
"essential", but after working with code that forbids exceptions and uses
explicit error status passing, I find exceptions very awkward to work with. I
find them a very lazy way of doing error propagation, which in turn encourages
lazy error handling.

~~~
bastih
Both standard library and other libs make use of them, so you often can't just
ignore exceptions.

Also agree on your point - I'm not saying I like exceptions, I like explicitly
passing type-encapsulated results/errors more for clarity. Exceptions happen
in a "second invisible lane" right next to the code you are writing, and for
example aren't immediately visible when reviewing code.

~~~
jcelerier
> Exceptions happen in a "second invisible lane" right next to the code you
> are writing, and for example aren't immediately visible when reviewing code.

hm, that's interesting - when doing C++ I always see the "bubbling-up" lane

------
jcelerier
> int* array = new int[n];

that's why you do `auto array = std::make_unique<int[]>(n);` (or `auto array =
std::make_unique_default_init<int[]>(n);` if you don't believe in your
compiler's ability to optimize redundant writes)

Also, this "memory leak" is only an issue on pre-1990 operating systems as
"current" operating systems have no trouble reclaiming unfreed memory - you
loose exactly the same amount of memory in both cases : zero.

So no, don't litter noexcept everywhere, especially for that, this article
just does not make sense.

~~~
shakna
> Also, this "memory leak" is only an issue on pre-1990 operating systems as
> "current" operating systems have no trouble reclaiming unfreed memory

Not just that, the OS is faster to reclaim the unfreed memory than if the
program was cleaning it up.

~~~
_rtld_global_ro
It's only true if the program is about to exit, for long running programs like
daemons, ``memory leak`` is still a thing.

------
wmu
A perfect example of the small-scale-example syndrome. As somebody else noted
here, throwing an exception in a noexcept context calls std::terminate.
Figuring out why terminate was triggered in a large, multithread program
sounds like a funny task until you have to do it by yourself.

The only place for noexcept are getters that return a copy of a POD value or a
(const-)reference. Placing noexcept anywhere else is a call for problems.

~~~
yrro
Can the terminate handler examine the stack and/or the thrown exception in
order to provide useful clues to the developer, or is it too late by then?

~~~
wmu
In GCC runtime the terminate handler is called after stack unwinding.

------
LessDmesg
Just use a finally block to free the array even in case of exceptions. Or does
C++ not have finally blocks?

~~~
rleigh
It does not have finally blocks. However, correct use of RAII should be used
to automatically free resources as they go out of scope.

