On Wed, 20 Aug 2008, Derek Gaston wrote:
> Specifically... all of the Trilinos stuff has NotImplemented throws in
> Of course, people really shouldn't be hitting that anyway (we don't
> advertise the Trilinos support yet). But, if some enterprising person
> did compile with Trilinos support and then try to run, say, Example3...
> they would immediately get a NotImplemented error that doesn't really
> explain much to them or us...
> Roy... are you saying you already put that Macro in there?
Yup, I committed it to libmesh_common.h this morning. Like I said,
for now it's just the same as libmesh_error() but throwing a different
exception with a different error message, so it wasn't a whole lot of
We'll eventually want to handle those differently, I think, but not
before 0.6.3 final. I've thought more about your idea of putting a
location-specific string in the exception constructors, and I think
you're probably right in the long run. That way application code that
wanted something different than cerr output could intercept exceptions
itself, and do something like an error file or a GUI dialog box if
that was preferable.
I still don't want to force library developers to choose those strings
by hand, but that shouldn't be a problem; we'll just modify
libmesh_error() and libmesh_not_implemented() to output to a strstream
instead of cerr, and then use the constructed string in the
constructor for the object we throw.
What do you think?