Derek Gaston | 20 Aug 06:15 2008
Picon

libmesh exceptions

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?

Derek
-------------------------------------------------------------------------
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
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Kirk, Benjamin (JSC-EG | 20 Aug 06:31 2008
Picon

Re: libmesh exceptions

Other constructors so as to provide an option?

No objection here...

-Ben



----- Original Message -----
From: libmesh-devel-bounces <at> lists.sourceforge.net <libmesh-devel-bounces <at> lists.sourceforge.net>
To: libmesh-devel <at> lists.sourceforge.net <libmesh-devel <at> lists.sourceforge.net>
Sent: Tue Aug 19 23:15:15 2008
Subject: [Libmesh-devel] libmesh exceptions

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?

Derek

-------------------------------------------------------------------------
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
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Roy Stogner | 20 Aug 06:52 2008

Re: libmesh exceptions


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=/
Derek Gaston | 20 Aug 16:34 2008
Picon

Re: libmesh exceptions

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=/
Roy Stogner | 20 Aug 16:49 2008

Re: libmesh exceptions


On Wed, 20 Aug 2008, Derek Gaston wrote:

> 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()");

I don't like that; in theory we can get at least that much info
automatically (minus transposition typos ;-) ) from the same stack
inspection + demangling calls that we use for tracefiles, and on other
systems we can at least get filename and line number automatically.

> If you come up with this Macro... just let me know what it is and I'll
> start using it!

libmesh_not_implemented();

It'll just do the same output as libmesh_error() (except for
mentioning "not implemented" instead of "logic error") for now, but
that'll at least allow looking at tracefiles or looking up file/line
numbers in source code to find the function name.
---
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=/
Roy Stogner | 20 Aug 16:53 2008

Re: libmesh exceptions


Oh, and I almost forgot to mention:

> If our intention is to really never use NotImplemented (except for
> whenever we're internally developing new features) that might be
> fine.

I'm thinking that NotImplemented throws will become a permanent part
of some library components: if someone tries to construct a p=0
LAGRANGE or p=1 CLOUGH element, for example, that's not really a logic
error on our part, that's the user asking for something that we can't
implement.

Those are just my half-formed thoughts on it, though.

> 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.

This is absolutely right.  But I hope file/line number/tracefile is
enough for now?
---
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=/
John Peterson | 20 Aug 17:32 2008
Picon

Re: libmesh exceptions

>> 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.

Uh oh.  What specifically are you referring to being not implemented?

--

-- 
John

-------------------------------------------------------------------------
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=/
Derek Gaston | 20 Aug 19:08 2008
Picon

Re: libmesh exceptions

On Wed, Aug 20, 2008 at 9:32 AM, John Peterson <jwpeterson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Uh oh.  What specifically are you referring to being not implemented?

Specifically... all of the Trilinos stuff has NotImplemented throws in it.

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?

Derek

-------------------------------------------------------------------------
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
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Roy Stogner | 20 Aug 19:20 2008

Re: libmesh exceptions


On Wed, 20 Aug 2008, Derek Gaston wrote:

> Specifically... all of the Trilinos stuff has NotImplemented throws in
> it.
> 
> 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
trouble.

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?
---
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
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Derek Gaston | 20 Aug 19:40 2008
Picon

Re: libmesh exceptions

On Wed, Aug 20, 2008 at 11:20 AM, Roy Stogner <roy-zwYCh+hlfMVg9hUCZPvPmw@public.gmane.org> wrote:
Yup, I committed it to libmesh_common.h this morning.

Thanks!
 
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.

This sounds like a good idea... and if it can be made automatic.... all the better!

The one thing I will say about manual strings is that it might provide more fine-grained error messages.  For instance, maybe there is a function that is mostly implemented except if something specific is passed in... in that case it might be nice to be able to hand code a message...

And in the spirit of thinking of GUI dialog boxes (ah - we dreaming big today!).... it would be great to have a general error object that we can throw with a specific text message that a GUI application could catch.  I'm not a huge fan of these schemes in general, but there are certain times that they make sense...

Derek
-------------------------------------------------------------------------
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
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Benjamin Kirk | 20 Aug 19:32 2008
Picon

Re: libmesh exceptions

>> Uh oh.  What specifically are you referring to being not implemented?
> 
> Specifically... all of the Trilinos stuff has NotImplemented throws in it.
> 
> 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...

Those would be mine...

In other news, I just installed trilinos/8.0.8 and will see if I can push
the integration a little further, again..

-Ben

-------------------------------------------------------------------------
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=/
Derek Gaston | 20 Aug 19:41 2008
Picon

Re: libmesh exceptions

On Wed, Aug 20, 2008 at 11:32 AM, Benjamin Kirk <benjamin.kirk-NSQ8wuThN14@public.gmane.org> wrote:
In other news, I just installed trilinos/8.0.8 and will see if I can push
the integration a little further, again..

Ben... I'm also working on this right now (with Trilinos 8.0.8).  I'm going to commit a few changes soon that will impact you... but I'll email the list about them (they have to do with TRILINOS_DIR).

I have a directive from my boss to "make this work now"... so I'm going to be pushing pretty hard on this.  I need NOX, AztecOO and Epetra working.  I'm going to start by just trying to get Example 3 to solve using AztecOO and Epetra in serial... then move on from there.

Let's coordinate on this.  Like I mentioned a little while ago, the hardest thing for me to get a grasp on is the parallel map / graph and how that translates into an Epetra_Map.... nudge, nudge.... wink wink....

Derek
-------------------------------------------------------------------------
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
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Benjamin Kirk | 20 Aug 20:12 2008
Picon

Re: libmesh exceptions

> Let's coordinate on this.  Like I mentioned a little while ago, the hardest
> thing for me to get a grasp on is the parallel map / graph and how that
> translates into an Epetra_Map.... nudge, nudge.... wink wink....

I will focus my effort on initializing the sparse matrix sparsity pattern...

-------------------------------------------------------------------------
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=/
Derek Gaston | 20 Aug 20:16 2008
Picon

Re: libmesh exceptions

On Wed, Aug 20, 2008 at 12:12 PM, Benjamin Kirk <benjamin.kirk-NSQ8wuThN14@public.gmane.org> wrote:
I will focus my effort on initializing the sparse matrix sparsity pattern...

Sounds good.

I think that in order to stay out of your way, I'm going to start writing the interface for the AztecOO linear solver.

Derek

-------------------------------------------------------------------------
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
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Gmane