RE: [stellation-res] Command line user diagnostics

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Sun, 2002-10-20 at 20:34, Jonathan Gossage wrote:
> > >-----Original Message-----
> > >From: stellation-res-admin@xxxxxxxxxxxxxxx
> > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> > >Chu-Carroll
> > >Sent: October 20, 2002 8:20 PM
> > >To: stellation-res@xxxxxxxxxxxxxxx
> > >Subject: Re: [stellation-res] Command line user diagnostics
> > >
> > >
> > >On Sun, 2002-10-20 at 20:03, Jonathan Gossage wrote:
> > >> I am finding quite a number of places in the command line
> > >implementation of
> > >> Stellation where errors in user input are resulting in stack
> > >trace dumps in
> > >> addition to problem text descriptions. I feel that it looks
> > >bad and serves
> > >> little troubleshooting purpose to include a stack trace for simple user
> > >> input errors. I feel that stack traces should be reserved for
> > >programming
> > >> errors only.
> > >>
> > >> How to the rest of you feel on this issue>
> > >
> > >I'm with you on this; in fact, I think I might even take a
> > >stronger stance than what you proposed. I don't think that
> > >a "production" version of Stellation should *ever* dump a stack trace
> > >unless the user specified debug mode.
> > >
> 
> Perhaps not to the console, but the stack trace should appear in the log
> otherwise trouble shooting is crippled.

That's basically what I meant by "unless the user specified
debug mode".  The logging code doesn't actually generate
any output unless logging is enabled by specifying a
debug level. I'd like the exception traces to only be
printed when logging it turned on.

> > >The code for handling errors is something that needs
> > >serious work before the release. Until recently, we've
> > >been working in debug mode. The error handling needs
> > >a thorough scan, the messages need to be improved (it
> > >often generates a generic error message and then prints
> > >the exception to provide specific information).
> > >
> > >	-Mark
> > >
> Sounds like it is time for another code review concentrating on this issue,
> but first I would like to get agreement on exactly how errors are to be
> handled. If we don't do this we will not ensure consistent handling of
> errors and will provide an uneven user experience.

I agree that a code review is definitely in order to
take care of this. I'm also with you that the error
handling needs to be made consistent, and that we need to
decide how we want the new uniform error handling to
work.  It's something that we've been planning on doing
for quite a while. We've been rather overwhelmed by a seemingly endless
series of deadlines, which is why we haven't gotten started on doing
anything about it yet. 


> 
> BTW: 1. Have tou had a chance to look at bug 25093.

I tried, but I'm having some browser troubles. I can't
seem to access the attachments; save link target won't
work, and whenever I select one it comes up in the browser display, and
then the browser locks up, and I can't save it.

Same thing happens under all of the browsers that I have
installed. I'll try upgrading my copy of mozilla tommorow,
and hopefully that will help. (You should have commit privs
by then, but I'd still like to be able to view bugzilla
attachments.)

>      2. Could you follow up tomorrow on committer priveleges. I have a bunch
> of Windows batch files almost ready for checkin and sending these my Email
> is not an option. Any Email with batch files attached gets the files
> stripped out very quickly.

The commit privs need to be approved by a member of the
Technology PMC, and they don't read email on the weekend. 
If the privs aren't approved by noontime tommorow, I'll
try to track down John Duimovich or Brian Barry by phone. 


>      3. I have only two of the script based test cases left to convert so
> that piece of the Windows port is almost complete.

Terrific!

	-Mark
-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx