Re: [Libmesh-devel] Possible code change

[Roy S. <ro...@st...>]

On Tue, 22 Jul 2008, John Peterson wrote:

> On Sat, Jul 19, 2008 at 5:42 PM, Nasser Mohieddin Abukhdeir
> <nas...@mc...> wrote:
>> Hi:
>>    I got a nasty surprise after I tried to use Hermite elements in my
>> simulation.  I got this error when I reran in debug mode:
>>
>> src/solvers/system_projection.C, line 665, compiled Jul 14 2008 at 22:27:45
>> terminate called after throwing an instance of 'libMesh::LogicError'
>>
>> and figured out that when I project my initial solution I need to also
>> provide a gradient for these higher order basis functions (which I
>> didn't need to do for Lagrange elements).  My question/comment is, is
>> there a better error behavior for this case (at least in debug mode)?
>> Maybe some error message (in the debug version) to let people know
>> specifically what the problem is?
>
> That may warrant an error message, but I'll let Roy be the judge
> though since I think that's his code.
>
> Generally, there are a lot of places in the code where we assert
> without giving a message, and in this case I think that the line
> number given and the comment above that line in the source code is
> clear enough as to what the problem is.
>
> Since all of our asserts are now libmesh_assert macros, it might not
> be too hard to have a second libmesh_assert() macro which takes a
> message to print in the case of assert failure.

Takes a message to print, throws a different exception, and maybe
isn't just dbg-only.

The twist here is that we're using *assert() in two conceptually
different situations: both when libMesh breaks internally (what I was
trying to get at with LogicError) and when libMesh is asked by the
user to do something it's incapable of.  In the former case, users
shouldn't need any more information than "tell the developers where
their code broke", so there's no need to even waste a few bytes on an
error-specific string.  In the latter case, we want a useful error
message, a different exception that robust user applications can know
to catch, and we probably want to make sure the assert is called even
in opt mode (in case the user does things like element selection at
runtime), although in cases like these we'll want to move the assert
out of loops first.

I'd like to think about this some more before adding a new macro
(libmesh_assert_user_input?  I can't even think of a good name yet),
so any other comments are welcome.
---
Roy