> Seems like a paradox: we can't call MPI_Abort from within error(),
> because error() can't be sure there isn't some enclosing code waiting
> to catch its exception, but we do have to be able to call MPI_Abort
> when error() is called if there is no catch waiting.
I like what you propose.
At ti
On Thu, 28 Feb 2008, Roy Stogner wrote:
> The only obvious problem is that this would break any old codes that
> don't call libMesh::init() from main(); I'm hoping that's not many
> users, but who knows.
Actually, the second obvious problem is that macro identifiers can't
have :: in the middle o
MPI_Abort() really means ABORT.
Specifically, when we call error() in parallel, we never make it to
std::abort(), which I'd been hoping to replace with throw
libMesh::LogicError(). This is fine if every process hits the error()
and the exception can't be caught; then it doesn't matter whether or
On Thu, 28 Feb 2008, Benjamin Kirk wrote:
> Go for it!!
>
>>> How well do exceptions work with threads?
>>
>> They're thread-safe, and they don't propagate from thread to thread.
>> So if one thread throws an exception and is able to recover from it,
>> the other threads aren't supposed even get
Go for it!!
>> How well do exceptions work with threads?
>
> They're thread-safe, and they don't propagate from thread to thread.
> So if one thread throws an exception and is able to recover from it,
> the other threads aren't supposed even get bothered by the process.
>
> I'm not sure how well
On Thu, 28 Feb 2008, John Peterson wrote:
> How well do exceptions work with threads?
They're thread-safe, and they don't propagate from thread to thread.
So if one thread throws an exception and is able to recover from it,
the other threads aren't supposed even get bothered by the process.
I'm
How well do exceptions work with threads?
-J
Stogner writes:
>
> On Thu, 28 Feb 2008, Roy Stogner wrote:
>
> > class LibMeshException : public std::exception
> >
> > class LibMeshInternalError : public std::exception
>
> That second class should drive from LibMeshException, not directl
On Thu, 28 Feb 2008, Roy Stogner wrote:
> class LibMeshException : public std::exception
>
> class LibMeshInternalError : public std::exception
That second class should drive from LibMeshException, not directly
from std::exception, of course. :-P
---
Roy
---
On Tue, 19 Feb 2008, Roy Stogner wrote:
> In the long run we should never be calling error(), just throwing
> exceptions. Even if the library has an error we can't recover from,
> that's no reason not to let the application using the library try.
I've recently become strongly motivated to make
