Paul Licameli
2016-11-25 18:26:32 UTC
James may or may not be curious to make a quick review my developing
project now.
I have updated the branch in my fork for Bug 437. I want to follow through
with what I started and make this project one of my first submissions to
2.1.4.
James, see how I define and use GuardedCall in the interests of "DRY".
Don't review every detail closely, those may change. But see how I avoid
repeated writing of try and catch blocks, by instead defining a function
that takes two lambdas, one for body and one for the handler. Also an
optional third lambda for the delayed action in the UI thread to alert the
user that something went wrong. This has its default.
Also see where I use GuardedCall. I decided several uses were really
needed. This includes the case of recording. But it does not include the
catch-call for event dispatch in AudacityApp::OnExceptionInMainLoop.
This project is expanding beyond the scope of the bug report and may give
us easier ways to write better error handling generally, not just for
exhaustion of disk resources. Failures of PortAudio functions might also
be treated this way.
But also part of doing things right is to use RAII idioms pervasively where
exceptions might pass and I am not confident our code does that. This
requires much review. I have now identified the set of functions I need to
review, which is large but feasible. But even if I put all missing RAII in
place, new code contributions by others need more careful review to ensure
continued good practice.
I do not intend to recover from throwing of std::bad_alloc. That is
becuase the possibilities for throwing this exception are pervasive, in our
code and also I imagine in wxWidgets code too. It may be intractible to
examine all of our code for possible memory exaustion exceptions and make
either strong or weak exception safety guarantees about the state of things
after stack unwinding. We can still treat bad_alloc as an asteroid strike
on the program.
But distinct from recovery from std::bad_alloc, is the possibility of
avoiding the throwing of it in the first place, with std::set_new_handler.
We can install our own function that tries to reclaim memory resources and
retry the allocation. Throwing away certain caches like those used in
drawing spectrograms is one possibility. Discarding some Undo history is
another.
Defining our own new_handler to prevent exceptions, I would consider a
separate project from my present one, which is for better handling of
exceptions. Maybe the new_handler is not worth doing. Maybe memory
exhaustion is a less likely occurrence, while disk space exhaustion could
happen if somebody tries to save a project directly to a limited external
storage device.
http://en.cppreference.com/w/cpp/memory/new/set_new_handler
PRL
project now.
I have updated the branch in my fork for Bug 437. I want to follow through
with what I started and make this project one of my first submissions to
2.1.4.
James, see how I define and use GuardedCall in the interests of "DRY".
Don't review every detail closely, those may change. But see how I avoid
repeated writing of try and catch blocks, by instead defining a function
that takes two lambdas, one for body and one for the handler. Also an
optional third lambda for the delayed action in the UI thread to alert the
user that something went wrong. This has its default.
Also see where I use GuardedCall. I decided several uses were really
needed. This includes the case of recording. But it does not include the
catch-call for event dispatch in AudacityApp::OnExceptionInMainLoop.
This project is expanding beyond the scope of the bug report and may give
us easier ways to write better error handling generally, not just for
exhaustion of disk resources. Failures of PortAudio functions might also
be treated this way.
But also part of doing things right is to use RAII idioms pervasively where
exceptions might pass and I am not confident our code does that. This
requires much review. I have now identified the set of functions I need to
review, which is large but feasible. But even if I put all missing RAII in
place, new code contributions by others need more careful review to ensure
continued good practice.
I do not intend to recover from throwing of std::bad_alloc. That is
becuase the possibilities for throwing this exception are pervasive, in our
code and also I imagine in wxWidgets code too. It may be intractible to
examine all of our code for possible memory exaustion exceptions and make
either strong or weak exception safety guarantees about the state of things
after stack unwinding. We can still treat bad_alloc as an asteroid strike
on the program.
But distinct from recovery from std::bad_alloc, is the possibility of
avoiding the throwing of it in the first place, with std::set_new_handler.
We can install our own function that tries to reclaim memory resources and
retry the allocation. Throwing away certain caches like those used in
drawing spectrograms is one possibility. Discarding some Undo history is
another.
Defining our own new_handler to prevent exceptions, I would consider a
separate project from my present one, which is for better handling of
exceptions. Maybe the new_handler is not worth doing. Maybe memory
exhaustion is a less likely occurrence, while disk space exhaustion could
happen if somebody tries to save a project directly to a limited external
storage device.
http://en.cppreference.com/w/cpp/memory/new/set_new_handler
PRL