lmi-commits
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]