From: Derek G. <fri...@gm...> - 2008-08-20 04:15:16
|
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 |
From: Roy S. <ro...@st...> - 2008-08-20 04:52:51
|
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 |
From: Derek G. <fri...@gm...> - 2008-08-20 14:34:57
|
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 |
From: Roy S. <ro...@st...> - 2008-08-20 14:50:03
|
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 |
From: Roy S. <ro...@st...> - 2008-08-20 14:53:50
|
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 |
From: John P. <jwp...@gm...> - 2008-08-20 15:44:57
|
>> 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 |
From: Derek G. <fri...@gm...> - 2008-08-20 17:08:39
|
On Wed, Aug 20, 2008 at 9:32 AM, John Peterson <jwp...@gm...> 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 |
From: Benjamin K. <ben...@na...> - 2008-08-20 17:33:00
|
>> 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 |
From: Derek G. <fri...@gm...> - 2008-08-20 17:41:56
|
On Wed, Aug 20, 2008 at 11:32 AM, Benjamin Kirk <ben...@na...>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 |
From: Benjamin K. <ben...@na...> - 2008-08-20 18:12:55
|
> 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... |
From: Derek G. <fri...@gm...> - 2008-08-20 18:16:33
|
On Wed, Aug 20, 2008 at 12:12 PM, Benjamin Kirk <ben...@na...>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 |
From: Roy S. <ro...@st...> - 2008-08-20 17:21:12
|
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 |
From: Derek G. <fri...@gm...> - 2008-08-20 17:40:33
|
On Wed, Aug 20, 2008 at 11:20 AM, Roy Stogner <ro...@st...> 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 |