From: David Wells 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 Step6 class, exactly where we have commented out @@ -583,8 +583,9 @@ double coefficient (const Point &p) } } @endcode -(Adding the Assert at the end ensures that an exception -is thrown if we ever get to that point -- which of course we shouldn't, +(Adding the Assert 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 p[0] 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::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::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 Step6::~Step6 () { @@ -265,7 +264,8 @@ void Step6::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(),