The macro sounds more like what I was thinking....
That said, the idea behind being able to pass a string in is that all
of your errors could have the same formatting. This is opposed to
just outputting something to std::cerr yourself first then
throwing.... which means every error will probably have a different
look.
I guess this all stems from me seeing the lines that look like:
terminate called after throwing an instance of 'libMesh::NotImplemented'
what(): Error: not implemented!
And thinking that that does no one any good at all. If our intention
is to really never use NotImplemented (except for whenever we're
internally developing new features) that might be fine. But if we
ship a release (like we just did) which has NotImplemented stuff being
thrown.... then we're not giving either our users or ourselves very
much info when someone runs into these cases.
For now, I do think I'll add another constructor for NotImplemented
that takes a string so that you can do:
LIBMESH_THROW(libMesh::NotImplemented("Something::somehwere()");
And get a message like:
terminate called after throwing an instance of 'libMesh::NotImplemented'
what(): Error: Something::somewhere() not implemented!
It's simple and will help for now.
If you come up with this Macro... just let me know what it is and I'll
start using it!
Derek
On Aug 19, 2008, at 10:52 PM, Roy Stogner wrote:
>
> On Tue, 19 Aug 2008, Derek Gaston wrote:
>
>> Any objections to making new constructors for both LogicError and
>> NotImplemented that take std::strings.... that way more useful
>> messages
>> (like _what_ isn't implemented) can be printed?
>
> No objections, but I'd like to know more about how these might be
> used. It seems to me that if the information in the string is just
> going to std::cerr, we might as well just send the string to cerr
> without passing it through an exception object first. Otherwise if
> there's information that a program incorporating the library can use,
> an arbitrary string probably isn't the best way to encode it.
>
> As for finding out what isn't implemented, couldn't we do that
> automatically by creating a libmesh_not_implemented() macro to use
> instead of just calling a raw LIBMESH_THROW(NotImplemented())? With a
> macro we could do the same thing libmesh_error() does and report file,
> line number, and stack trace information.
> ---
> Roy
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
