On 8/3/23 11:25, Simon Wiesheier wrote:
The reason why I wanted to use an
try/catch block is to surrogate the use of an if-statement.
Consider these two variants:
Variant 1:
disable_abort_on_exception();
try
{
feValues.reinit(cell,...);
}
catch(dealii::Exception Base exception & )
{
Assert(checkSecondRunTimeCondition, ...)
// do something
}
Variant 2:
if(cell->state()==-1)
{
Assert(checkSecondRunTimeCondition, ...)
// do something
}
else
{
feValues.reinit(cell,...);
}
As you can see, there are two conditions I have to check at every quadrature
point.
Clearly, Variant 2 implements an if-requests and is probably not the way to go.
Variant 2 is what I would have done.
Why do you care about the 'if'? Are you worried of the run time overhead? If
that's the case, consider the equivalent cost of a 'throw' and 'catch' -- I
would not be surprised if that were two order of magnitude more expensive than
the 'if'.
1. So with regard to performance, would you prefer Variant 1
(as the try/catch introduces less overhead compared to the if-statement)?
That's something you can test. There is a general rule that even good
programmers cannot tell where the bottlenecks of their code are unless they
benchmark them. I would suggest writing a small test program that checks these
two options!
2. If so, is the call of "disable_abort_on_exception()" good
coding practice or would you refrain from doing so?
In the main function of our program, we have a try/catch with
catch(dealii::ExceptionBase exception &).
Given that, in my opinion "disable_abort_on_exception()"
should cause any undue behavior.
It's not good practice. As Matthias already pointed out, it doesn't work in
release mode. It's a tool we only use in the test suite.
Best
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/aafdc3fd-de77-842f-b4e5-64127a5abf76%40colostate.edu.
