[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi-commits] [lmi] master 66a3876 1/3: Further improve std::uncaught_ex
From: |
Greg Chicares |
Subject: |
[lmi-commits] [lmi] master 66a3876 1/3: Further improve std::uncaught_exceptions() commentary |
Date: |
Tue, 27 Mar 2018 19:19:43 -0400 (EDT) |
branch: master
commit 66a38760020d27944f17dce67b44f2732ef55c99
Author: Gregory W. Chicares <address@hidden>
Commit: Gregory W. Chicares <address@hidden>
Further improve std::uncaught_exceptions() commentary
---
handle_exceptions.hpp | 3 +++
progress_meter.hpp | 8 ++++----
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/handle_exceptions.hpp b/handle_exceptions.hpp
index d688c8c..e56c3ce 100644
--- a/handle_exceptions.hpp
+++ b/handle_exceptions.hpp
@@ -96,6 +96,9 @@ class stealth_exception
///
http://groups.google.com/group/comp.lang.c++.moderated/msg/aa7ce713ee90c044
/// "The only problem with uncaught_exception is that it doesn't
/// tell you when you're in a catch(...) { ... throw; } block"
+/// and see also:
+/// https://lists.nongnu.org/archive/html/lmi/2018-03/msg00100.html
+/// "uncaught_exception{,s}() would always return {false,0}" here.
///
/// See
/// http://article.gmane.org/gmane.comp.gnu.mingw.user/18355
diff --git a/progress_meter.hpp b/progress_meter.hpp
index f6b24ee..634f00c 100644
--- a/progress_meter.hpp
+++ b/progress_meter.hpp
@@ -138,10 +138,10 @@
/// is taken as a postcondition of code that uses the progress meter,
/// so it might seem natural to test it in this class's dtor; however,
/// the postcondition won't be established if the metered loop is
-/// exited by throwing an exception. Perhaps std::uncaught_exceptions
-/// could distinguish that special case, but as this is written in
-/// 2007-06 some compilers don't implement that standard facility
-/// reliably. Postcondition failure engenders only a warning because
+/// exited by throwing an exception. Today, std::uncaught_exceptions()
+/// could distinguish that special case, but that was not reliably
+/// possible when this was designed in 2007; there's no need to change
+/// it now. Postcondition failure engenders only a warning because
/// of other possibilities--e.g., a loop might throw an exception
/// inside a try-block whose catch-clause doesn't rethrow; perhaps it
/// would be better to throw an exception instead, depending on the