Re: fhpd vs RuntimeExceptions

[Mark Wielaard <mark@klomp.org>]

We quickly went over this on the meeting just now.
Just a summary to see if I got it all.

On Wed, 2007-11-14 at 09:44 -0500, Andrew Cagney wrote:
> Mark Wielaard wrote:
> > While investigating some bugs I noticed that the fhpd sometimes swallows
> > the RuntimeExceptions from the core (and there I thought all was
> > fine...).
> Just fyi, broadly the message stuff, at least for normal output, is 
> going away.
>
> The reason is that the cli alternates between using addMessage and 
> PrintWriter.print(...) for normal out; so I've been migrating stuff to 
> just do PrintWriter.print.  But this leaves us still needing a way to 
> consistently report errors.

OK, good to know, I had only seen the Message variants in the code that
I looked at. The (add)Message stuff had one benefit that it concentrated
the generation of Messages so you can easily capture any exception
causes, which may patch added. When using "raw" Printwriter calls you
would need some way to capture and then report the errors indeed.

> >  This makes debugging the fhpd itself a little hard. I added a
> > possible exception cause to the Message class and while I was at it
> > added checks to make sure we don't present the user with an empty or
> > null message (which is very uninformative). Currently we always print
> > these possible exception causes when they are attached to a Message in
> > CLI.flushMessages().
> 
> We were printing both the error and the stack, that looked terrible (the 
> number of times an exception occurs for legitimated reasons is 
> surprising); so they were turned off.  Did this turn them back on?

The cases I looked at were things like:
http://sourceware.org/bugzilla/show_bug.cgi?id=5286
http://sourceware.org/bugzilla/show_bug.cgi?id=5267
Where there was an internal RuntimeException without a message so you
would just see Error: null or Error: "" without any extra info.

In those cases when you have an internal RuntimeException you now attach
a exception cause to the message (and currently always print it, but
that can certainly be made optional - either with a command line option
to fhpd when started up or by setting some internal variable - see help
set).

The main problem seems to be how to categorize RuntimeExceptions.
Currently we are mixing internal ones, that should never occur and when
they bubble up to the fhpd CLI level should really be reported and
"expected" RuntimeExceptions that "mean" something at the fphd level and
for which only the message might make sense.

Cheers,

Mark