Re: fhpd vs RuntimeExceptions

[Mark Wielaard <mark@klomp.org>]

Hi Andrew,

On Wed, 2007-11-14 at 12:31 -0500, Andrew Cagney wrote:
> from the call; what about:
>   CLI.printError(String)
> and/or/...
>   CLI.printError(Exception)

You mean to replace CLI.addMessage() and do the user feedback directly
instead of stacking it in a Message queue and then replaying it? Yes,
that makes sense. The current setup does feel a little over-engineered.

[There is the issue that you don't have a strong connection to the
original Command executed by the user for which this is a response, but
we didn't have that in the case of the (add)Message constructs in the
first place, so that might not matter at this point. Since from the user
point of view the fhpd is single threaded and accepts just one command
at a time. It might matter in the future for the gui though since that
could be issuing multiple commands at the same time and then you want to
have a stronger tie between the issued command and the user response or
error message.]

> the "logic" deciding what to do with the exception; for instance if 
> Exception.getMessage() is null/empty then things are bad; dump the 
> back-trace; but otherwise just print the message (That should cover null 
> pointer exceptions).

I don't think that is the right logic. There are also other
RuntimeExceptions like ArrayOutOfBoundsException, ArithmeticException,
IllegalArgumentException or NumberFormatException, etc. that don't have
empty messages, but that are real core bugs if they occur and "bubble
up" to the CLI. Just printing the message isn't enough information for
the user to see what really went wrong.

If the Exception is truly meant to convey information to the end user in
relation to a specific command it should be more explicitly communicated
than just by any generic RuntimeException.

Cheers,

Mark