Re: fhpd vs RuntimeExceptions

[Kris Van Hees <kris.van.hees@oracle.com>]

On Wed, Nov 14, 2007 at 09:44:08AM -0500, Andrew Cagney wrote:
> Mark Wielaard wrote:
>>  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?

While exceptions definitely are expected to occur primarily for legitimate
reasons, exceptions should hardly ever be simply printed (along with the stack)
because that is pretty much equivalent to not handling it.  Some might be
very simple cases of needing to write out a message indicating the exception
or error, but that is usually more exception than rule.  Turning it off is
not quite the answer either I think.  Leaving it in the state where it spews
out excessive information might be better along with bugs filed for the pieces
of code that are failing to handle the exceptions appropriately.  Otherwise
we are simply hiding problems, and making debugging fhpd a lot more difficult
as Mark points out.

I've found it quite convenient in various projects that deal with this type of
issues (Java-based and otherwise) to rather ensure this output goes to stderr
so it can be redirected to a file for later examination, as to not interfere
with the interactive session.  And when specifically debugging some of those
issues, not redirecting so they show up inline where they make most sense.  Any
form of stopping them from being printed has always led to somehow delaying the
resolution of the issues that cause the problem in the first place.

	Cheers,
	Kris