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