On Tue, 19 Feb 2008, John Peterson wrote:
> Benjamin Kirk writes:
> > The whole point of here() is to tell you were it was called, not to always
> > return "libmesh_common.h"....
A few random impractical thoughts:
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'd like for us to get not just a line number but a stack trace (i.e.
with print_trace()) whenever we hit an error(), at least if our
compiler options give enough symbol info to make the trace somewhat
meaningful. That could be done easily enough... but I'd also like a
stack trace whenever we fail an assert() and (eventually) whenever we
throw an uncaught exception. The former would require us to replace
assert()s with libMesh_assert()s, and the latter could probably only be
easily implemented by the gcc/glibc/libstdc++ developers.
print_trace() gives a whole stack trace, and currently only prints
function names (uncomment those four lines to print more), but the
same code could be modified to only print out the details of the frame
from which print_trace() was called. That might be as good as
__FILE__ and __LINE__, if we made it portable to more than just
gcc/glibc/libstdc++; in that case we could have inline functions
rather than macros for error()/here()/etc.
> > So what now -- to we go gcc-ish and replace them with __libmesh_here() etc??
> Well, maybe not the double leading underscore but libmesh_error()
> seems more reasonable than the naked error() that we have now. Maybe
> also all capital letters to distinguish it as a macro, but I don't
> want to get too Fortran77.
libMesh_error(), libMesh_here() would get my vote. (again, that's
assuming we keep around a deprecated here() and error() through 0.7.0
unless some ./configure option says otherwise)