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 & )
{
As
" So I am not sure how you would ever use an `Assert(...)` in optimized
release mode (where you want to run your program to get any
performance). "
I was indeed considering my program in debug mode.
Based on what you said, there is no way for me to catch
the failed .reinit call in optimized releas
Have you considered looking into our FEPointEvaluation [1] and related
"nonmatching" facilities?
I have the feeling that we already provide the right data structures for
your interpolation/evaluation needs - in particular with an efficient
and fast implementation. An example usage can be found in
I am a bit confused.
In optimized release mode the `Assert` are reduced to a nnop and will
not abort (or throw an exception). For user-visible/induced runtime
errors we have `AssertThrow` which will throw an exception (and not
abort a program). In summary:
- we use `Assert(...)` in the library
Let me please clarify my last concerns in this regard:
The operations
GridTools::find_active_cell_around_point and
feValues.reinit
are executed at quadrature point level and performance
is really important in our application.
The reason why I wanted to use an
try/catch block is to surrogate the u
On 8/2/23 15:58, Simon Wiesheier wrote:
Does that make sense?
Or do you see a better solution, like checking
cell->status() right after GridTools::find_active_cell_around_point?
This. If the function you call returns an error code in the form of an end
iterator, just test for that rather than
" You can call
deal_II_exceptions::disable_abort_on_exception();
which converts the call to abort() to raising an actual exception. "
This worked indeed.
" But I do want to ask what you plan to do if you derefernce an
end-iterator. "
I see your point, let me briefly sketch what I want to do:
On 7/30/23 11:20, Simon Wiesheier wrote:
Of course, it does not make sense to dereference such an iterator.
That's the reason why I wanted to catch this operation, and do something else
instead. In my case, aborting the program is absolutely not necessary as I
would have a workaround.
But, i
"
The
former is for logic errors inherent in the program that cannot be recovered
from -- say, trying to dereference triangulation.end()"
Of course, it does not make sense to dereference such an iterator.
That's the reason why I wanted to catch this operation, and do something
else instead. In my
Simon,
I want to catch exceptions thrown by fePointEval.reinit(...),
where fePointEval is an object of type FEPointEvaluation.
Here is a snippet of code demonstrating the issue:
try
{
fePointEval.reinit(...);
}
catch(dealii::ExceptionBase & exception)
{
std::cout<<"exception is
Dear all,
I want to catch exceptions thrown by fePointEval.reinit(...),
where fePointEval is an object of type FEPointEvaluation.
Here is a snippet of code demonstrating the issue:
try
{
fePointEval.reinit(...);
}
catch(dealii::ExceptionBase & exception)
{
std::cout<<"exception is c
11 matches
Mail list logo
