Paras,
I am trying to work on the exception handling aspect of my code, which employs
dealii::Workstream::run() for thread based parallelization of FE system
assembly. The code employs the Assert and AssertThrow macros, in conjunction
with dealii::ExcMessage(), at several places with in the source code. The
dealii::deal_II_exceptions::disable_abort_on_exception() command is used to
ensure all Assert macros throw as well.
It is desired that the exception thrown from within a function is propagated
up to the main function, where it can be caught so that the code can be
"elegantly" exited instead of being aborted.
The procedure works fine for exceptions thrown from single threaded functions
but I get the following error for an exception thrown from the multi-threaded
assembly function.
---------------------------------------------------------
In one of the sub-threads of this program, an exception
was thrown and not caught. Since exceptions do not
propagate to the main thread, the library has caught it.
The information carried by this exception is given below.
---------------------------------------------------------
Having a look at the source code reveals that this is the intended behavior
for exception being thrown from a sub-thread, but I am not able to understand
why this is so. Alternatively, is there some way other out to ensure that the
such an exception is propagated to the main ?
This is actually very difficult to achieve. I made that work for the 9.3
release when you use `new_task()`, and I think one could probably make that
work for `new_thread()` as well based on features C++11/14 provides. But I
don't think this is easily possible when using WorkStream and it's not clear
to me to begin with what kind of semantics this would have. Your best bet is
to ensure that functions you call via WorkStream do not throw exceptions.
As for turning Assert into throwing exceptions instead of aborting the
program: The way we treat the conditions used in Assert statements is that
they are irrecoverable: There is nothing you can do to make the program do
anything useful if you trigger an Assert, and as such aborting the program is
the correct choice: You just need to fix the program. A properly debugged
program should never run into an Assert statement.
Best
Wolfgang
--
------------------------------------------------------------------------
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/60650e30-d1e6-6ad0-8eab-35e6e443d621%40colostate.edu.
