Re: Debuglevels, assertions

[Christian Reiniger <warewolf@mayn.de>]

Adrian Ratnapala wrote:

> > I *think* it should throw an exception (ppEAssertionFailed) instead of
> > exit()ing. That makes it possible to recover from the error (useful in some
> > cases) and the exception bloat doesn't really matter as it exists only in
> > the debug version. Comments?
>Why is being able to recover from a failed Assert() usefull?

Not sure. I thought perhaps if Assert () is used for method parameter
checking... sometimes it's possible for the caller to recover from that.

> > Apropos exceptions: The exception class has to be extended to include the
> > __LINE__ and __FILE__ infos. If we wrap the throwing in some ppThrow ()
> > macro then that's easy. Countervoices? No? Ok.
>Maybe.  We are very worried about bloating the final product remember,
>maybe if ppThrow only does this in debuggin, I don't know. Actually I

Let's see, we have several "exception categories":

* Exceptions used for debugging. Those should only be caught by some
toplevel error message dumper, exiting the app. Those should include as
much info as possible, including __LINE__ etc, but they also have to be
used only while debugging. I'd use a ppThrow () macro for this.

* Exceptions indicating fatal errors that are not handled by the lib. Checks
that can't be made obsolete by debugging, errors that have to be reported
to the calling app. Mostly caught by that app. Here detailed info isn't
really important, but some human-readable info should be there in case the
app does *not* handle it. The scheme used up to now looks good for this.

* Exceptions that *are* handled by the lib internally. Here textual info is
completely unneccessary. Some default (parameterless) Exception
constructors setting all fields to empty strings should be the best.

>thought these went in the existing "location" field, but its probably
>better that they do not.

There's a "originating function" field...


Cu
	Christian
--

Error 032: Recursion error - see error 032