From: David Wells <wellsd2@rpi.edu>
Date: Mon, 30 Apr 2018 22:11:08 +0000 (-0400)
Subject: Fix some documentation regarding exception handling.
X-Git-Tag: v9.0.0-rc1~53^2
X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=402487ea8e86813a871e3cf3b8c6b9a1e547ebb6;p=dealii.git

Fix some documentation regarding exception handling.
---

diff --git a/examples/step-6/doc/results.dox b/examples/step-6/doc/results.dox
index 2c027fb721..6f4bf6376c 100644
--- a/examples/step-6/doc/results.dox
+++ b/examples/step-6/doc/results.dox
@@ -157,7 +157,7 @@ victim: The one object that still uses the SparsityPattern is the
 SparseMatrix.
 
 The stacktrace gives an indication of where the problem happened. We
-see that the exception was triggered in the
+see that the AssertNothrow macro was triggered in the
 destructor of the SparseMatrix class (which inherits from Subscriptor) that was called
 through a few more functions from the destructor of the
 <code>Step6</code> class, exactly where we have commented out
@@ -583,8 +583,9 @@ double coefficient (const Point<dim> &p)
     }
 }
 @endcode
-(Adding the <code>Assert</code> at the end ensures that an exception
-is thrown if we ever get to that point -- which of course we shouldn't,
+(Adding the <code>Assert</code> at the end ensures that either an exception
+is thrown or that the program aborts if we ever get to that point
+-- which of course we shouldn't,
 but this is a good way to insure yourself: we all make mistakes by
 sometimes not thinking of all cases, for example by checking
 for <code>p[0]</code> to be less than and greater than zero,
diff --git a/examples/step-6/step-6.cc b/examples/step-6/step-6.cc
index 5607e28b68..e5702773b2 100644
--- a/examples/step-6/step-6.cc
+++ b/examples/step-6/step-6.cc
@@ -205,8 +205,8 @@ Step6<dim>::Step6 ()
 // their declaration in the class), as always in C++. Thus, the
 // SparsityPattern will be destroyed before the SparseMatrix, since its
 // declaration is below the declaration of the sparsity pattern. This triggers
-// the situation above, and without manual intervention an exception will be
-// raised when the SparsityPattern is destroyed. What needs to be done is to
+// the situation above, and without manual intervention the program will abort
+// when the SparsityPattern is destroyed. What needs to be done is to
 // tell the SparseMatrix to release its pointer to the SparsityPattern. Of
 // course, the SparseMatrix will only release its pointer if it really does
 // not need the SparsityPattern any more. For this purpose, the SparseMatrix
@@ -215,9 +215,8 @@ Step6<dim>::Step6 ()
 // the SparsityPattern to 0. After this, you can safely destruct the
 // SparsityPattern since its internal counter will be zero.
 //
-// For completeness, we add the output of the exception that would have been
-// triggered without this destructor, to the end of the results section of
-// this example.
+// We show the output of the other case (where we do not call
+// SparseMatrix::clear()) in the results section below.
 template <int dim>
 Step6<dim>::~Step6 ()
 {
@@ -265,7 +264,8 @@ void Step6<dim>::setup_system ()
   // boundary conditions after assembly, like we did in earlier steps: instead
   // we put all constraints on our function space in the ConstraintMatrix. We
   // can add constraints to the ConstraintMatrix in either order: if two
-  // constraints conflict then the constraint matrix will throw an exception.
+  // constraints conflict then the constraint matrix either abort or throw an
+  // exception via the Assert macro.
   VectorTools::interpolate_boundary_values (dof_handler,
                                             0,
                                             Functions::ZeroFunction<dim>(),