Fw: [getting OT ...] Re: [antlr-interest] exceptions in the lexer

[Harald Mueller]

> 
> ----- Original Message ----- 
> From: "Harald Mueller" <harald.m.mueller at bigfoot.com>
> To: <antlr-interest at yahoogroups.com>
> Sent: Wednesday, December 08, 2004 10:19 PM
> Subject: Re: [getting OT ...] Re: [antlr-interest] exceptions in the lexer
> 
> >  (I once had to work with a database which, after some internal error,
> > continued - but the data in a whole table were garbled. In that case,
> I'd
> > very much have preferred a simple and shocking crash!).
> 
> Stopping access to the database is good in this case, a shocking crash
> is simple for the programmer but is impolite to the user
> and unfairly moves the blame from the database
> to your application.

IMHO, no: I dont care for who is blamed: But I wont program around database
errors. Rather, the whole thing should come down, hopefully even including
the next layer, namely the business process which uses the application. 

My experience is that some errors will only be remedied organizationally if
"half of the company" (i.e., some important business process) comes to a
grinding halt. This is a maybe unfair means of escalating some problems -
but it is simply necessary.

The users should actually get a shock in that case.

> Let's encourage the programmer not to take the simple way out
>  } catch ( ) {
>    t.printStackTrace();
>    System.exit(1);
> }
> but try for something better.

t.printStackTrace() is not ok.

But showing the user

   Internal error: please enter a short description of what you did and
       press "Send error email". Application will then exit - sorry.

and then, after the user has done so:

   EMail sent to "hotline.<this application>@mycompany.com", including
   your description and some internal technical information [i.e.,
stacktraces].
   You may also contact the hotline for this application at 1234 with the
following error id: 9999!
   Now I have to stop the application.

and THEN EXIT MERCILESSLY (but not System.exit() - do a throw up to the
outermost thread layer so that various finally blocks can do their work).

It seems the hard thing is really to distinguish between the optimistic
case/stance ("it will most probably be ok if we continue even after a
generic Exception/Throwable") and the pessimistic/paranoid approach ("in
undefined states, we expect systems to destroy our business-critical data,
so by default, we exit/stop/escalate the problem").

Regards
H.M.Müller

> 
> As long as the OS/JVM is running at least the shell of your application
> should run.
>  
> matthew
> P.S thanks for the stimulating discussion.
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 

-- 
NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/