Eradicate exceptions without argument

[bangerth]

One of the first lessons I teach my students is to read the error messages. Once they get used to it, it actually works reasonably well. But only for those errors that do actually print anything useful. Many of our messages do that, but we have ~250 exceptions declared with DeclException0 that, in essence, only print the name of the exception but nothing else. I think the original idea was that the name of the exception is a giveaway, but I find now that that was a failed hope.

In other words, we need to get rid of this!

[tjhei]

Good idea. I vote for adding a text argument (optional?) to ExcInternalError and ExcNotImplemented. The reason is that I often end up using ExcMessage because I can not add a short description. I guess ExcMessage should be a last resort.

I am happy to do this if you agree.

[bangerth]

I think ExcInternalError is truly an internal error only developers should be get (or that at the very least require a developer to fix). ExcNotImplemented could take an argument though I'm not sure what one would say? I'm definitely ok with it, though, if you want to add an argument and go through our code base to change it throughout (for both of these exceptions).

I've been using ExcMessage in the more recent past for all of those cases where there is no actual data to be printed (so where I would have used something declared with DeclException0 in the past). I think it's not just a last resort -- I think it's a legitimate way to provide some description of what the error means and how it may have happened. Whether you have a name for the exception class or not doesn't matter in that case.

[tjhei]

The reason I bring this up is because you introduced code of the form ExcMessage("Internal Error: ...") (see 96e0ffb). I don't care strongly about all this, but I always tried to shy away from ExcMessage because it is not descriptive, hard to grep for, and awful to catch. It is easy to have a sentence of why I think this is an internal error (I don't want to require a message of course).

[bangerth]

That's a good point. I'll have to think about this.

Maybe we should just think about an alternative way of using DeclException0. Let's say something like DeclExceptionMsg that creates an exception class that takes no argument, but where the exception declaration still contains a descriptive string. Thinking about it, that actually seems like the best of all worlds since it only requires changing the one place where we currently declare the exception. What do you think?

[tjhei]

Yes, that is what I meant. As long as we make it optional so we don't have to go through the whole library. Maybe something like (edit: or call it DeclExceptionMsg):

 #define DeclException0(Exception0, defaulttext) \
class Exception0 :  public ::ExceptionBase \
{ \
public: \
Exception0 (const std::string & msg = defaulttext) : arg1 (msg) {}                            \
virtual ~Exception0 () throw () {}                                    \
virtual void print_info (std::ostream &out) const {                   \
  out << arg1 << std::endl;                                       \
}                                                                     \
private:                                                                \
const std::string arg1;                                                     \
}

So we can do this:

   DeclException0 (ExcInternalError, "This exception usually indicates that some condition which the programmer thinks must be satisfied at a certain point in an algorithm, is not fulfilled.");

  AssertThrow(dim<3, ExcInternalError());
  Assert (next_unused_vertex < triangulation.vertices.size(),
                    ExcInternalError("Internal error: During refinement, the triangulation wants to access an element of the 'vertices' array but it turns out that the array is not large enough."));