Re: fhpd vs RuntimeExceptions

[Mark Wielaard <mark at klomp dot org>]

Hi Andrew,

On Fri, 2007-11-16 at 09:31 -0500, Andrew Cagney wrote:
> True, it gets rid of the immediate problem.  More importantly it lets us 
> walk away from this bike shed and focus on more critical - a corrupt 
> variable or wrong back-trace is far more serious than the exact text of 
> an error message.  Just like how the dog hears in the farside cartoon 
> <<Rover, blah blah blah ...>>, we've ensured that the user at least sees 
> "Error: ".  As our user base expands we can refine this.

The immediate problem is not nice error messages (which would be
somewhat of a bikeshed that I wouldn't even try to get incolved with
seeing I am not even a native speaker). The problem is how we and our
users can help each other pinpointing bugs in our code. For example I
had to debug a monitor lock issue last Friday. The current setup doesn't
show me any stacktraces to help me so it is hard to see where this came
from. Hiding information from the current users (us!) is not the right
default imho. If unexpected exceptions happen the default should be to
show all information to help our users and developers to get at the root
cause.

> > That seems fine. I recommend you also just rip out the whole Message
> > queuing structure and handle that in the same way with a simple
> > printMessage(). Having two different mechanisms for creating user
> > feedback in the CLI is probably confusing.
> >   
> Of course; however the cli code base is still in rehab from me 
> refactoring N ways of implementing a command down to one.
> Can you create a bug?

Here you go: http://sourceware.org/bugzilla/show_bug.cgi?id=5402

Cheers,

Mark