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

matthew ford Matthew.Ford at forward.com.au
Wed Dec 8 02:15:48 PST 2004 

Thanks for that Harald,

>>From a programmer's point of view I don't disagree, much, with what you have
to say.

However I tend to take an un-usual view point for a programmer
That is the view from the user's perspective.

Looking at this from my user's view, I never ever want my application to
just shut down while I am trying to use it.
At the very least I want a polite informative  (not patronizing) message
letting me know why the application did not do what I just requested it to
do.
But more resonably I want to be able to continue to do what ever else I can
do
with those parts of the application that still work.  I want to stay in
control of when I
stop working with this application.

As a user, I don't care if the error is a RuntimeException, an Error or
an SQLWidgetIOGoneFunnyException, I only care that the application did not
do what I asked and "What has happened to all that work I just did!!??"

In the JEdit OutOfMemory example, I can continue to do almost
every thing I want even after the error occures.  I just cannot open that
particular
very large file.
This is what I strive to provide to all the users of my programs.
I cannot guarantee that my programs will be error free but I can
say to them

"I am not going to kick you off in the middle of your work just
becuase I made a programming error in one module or just
because you did something the application/hardware could not
cope with"

To meet this promise I have to catch ALL Throwables and try
and recover.  As you noted this can and does involve more work
then just shutting down on any error.

But the users deserve better behaved programs then they are
getting at the moment and more work for us programmers
 will keep the bills paid so why not do it.

matthew

P.S. another hobby horse of mine, not un-related to error recovey,
is the provision of a comprehensive undo facility (not just for text
editing).

----- Original Message ----- 
From: "Harald Mueller" <harald.m.mueller at bigfoot.com>
To: <antlr-interest at yahoogroups.com>
Sent: Wednesday, December 08, 2004 8:25 PM
Subject: Re: [getting OT ...] Re: [antlr-interest] exceptions in the lexer


>
> Maybe I should cite here the slides from my Java course about Exception
> handling ... a short summary of my advice:
>
> RuntimeExceptions have three main uses:
>
> a. Working around "checked exception" boundaries (usually by wrapping a
> checked exception). However: Before doing this, change the interface so
that
> it allows the additional Exception. Only when you cannot do this (or don't
> want to - see also c.), use the wrapping.
>
> b. Signalling programmer errors (e.g. IllegalArgument, IllegalState,
> NullPointer). Before catching them, spend as much time as possible on
> *correcting* the programmer error. If this is not possible (external
> sources) or if programmer errors are legitimate according to the spec
> (high-availability software - programming Space Shuttle software in
Java?),
> then catching them is necessary - but that should raise a red flag in
> project and quality management!
>
> c. Sometimes, signalling "unexpected environment exceptions" (e.g.
> EJBException, exceptions in JDO) that can happen "everywhere" in that
> environment. There is still some debate whether one should use this design
> at all, but the "no checked exceptions" party is growing; and
if/when/where
> they are right, catching those RTExceptions is right. However, this
requires
> a spec as to how to proceed: In many cases, the internal state of the
> program is still ok, and then proceeding is no problem; however, in some
> cases, a "subsystem" may have gone into an unusable state due to the
> exception - and then you must either
> (*) re-initialize the subsystem; or
> (*) "shut it off", i.e., disable its use by other subsystems/services -
> which may entail other disablings relying on those subsystems/services. If
> you don't think about this, your system might "limp along" for some more
> time and then still fail - but now, finding the problem is much harder
than
> with "early failure".
>
> So, in general, I'm wary of catching RuntimeExceptions.
> At least, log all of them reliably(!) somewhere where they can be and
are(!)
> read!
>
>
> Errors have two main uses:
>
> d. Signalling "very unexpected program state exceptions" (AssertError).
> This is like b. above: Dont catch it, correct the problem.
>
> e. Signalling "unexpected JVM exceptions" (OutOfMemory, ThreadDeath).
> This is like c. above: Catch it if it pays; but be aware and specify what
> should happen if subsystems go out of order.
>
> Thus, I'm not so wary of catching Errors. But still, logging is required.
>
>
> Regards
> Harald M. Mueller
>
> >
> > Yes it may not work in some cases but in those cases that it does
> > you have allowed the user to save the work they have done and continue
to
> > work using other areas of the application .
> > In the JEdit example, all this error means is that you cannot open that
> > particular file
> > as it is too large. Your existing edits are not dumped by a programmer
who
> > is too lazy (timid?) to try and recover from errors.
> >
> > In those cases where you cannot recover, what have you lost by trying?
> > What was the alternative to trying to recover?
> > Just shutting down the application and loosing all the user's existing
> > work!
> > No merit points for doing that.  Your application will get a reputation
as
> > being
> > unreliable.
> >
> > I want to program robust applications.  I want to keep trying to recover
> > from
> > ALL Throwables untill the the JVM or the OS dies.
> > The user deserves as much.  If the JVM or OS dies as a result of an
error
> > trying to recover does not make it worse.
> >
> > Programming errors during the developement of my Parallel program
> > (www.forward.com.au)
> > regularly caused it to try and recovere from NullPointers,
> > ArraysOutOfBounds
> > and
> > OutOfMemory.  These errors never shut the whole application down.
> >
> > Java's advanced garbage collection means it is much more robust in the
> > face
> > of errors then
> > previous languages.  But it seems programmers (and even the language
> > designers) do not
> > realize how robust it is.
> >
> > In many cases you can sucessfully recover from Errors and
> > RuntimeExceptions.
> >
> > It is dissapointing that the text books have trained a generation of
Java
> > programmers who
> > will not even try.
> >
> > matthew
> > ----- Original Message ----- 
> > From: "Harald Mueller" <harald.m.mueller at bigfoot.com>
> > To: <antlr-interest at yahoogroups.com>
> > Sent: Tuesday, December 07, 2004 9:56 PM
> > Subject: [getting OT ...] Re: [antlr-interest] exceptions in the lexer
> >
> >
> > >
> > > >
> > > > Well JEdit catches this and recovers.
> > > > Why can't I?
> > >
> > > You can :-) But there's no guarantee it works. Here is the text from
the
> > JLS
> > > (section 8.4.4) - which I interpret as a more constructive comment
than
> > > mine:
> > >
> > > > Exceptions that are represented by the subclasses of class Error,
for
> > > example OutOfMemoryError, are thrown due to a failure in or of the
> > virtual
> > > machine. Many of these are the result of linkage failures and can
occur
> > at
> > > unpredictable points in the execution of a program. Sophisticated
> > programs
> > > may yet wish to catch and attempt to recover from some of these
> > conditions.
> > >
> > > Regards
> > > Harald M. Mueller
> > >
> > > > matthew
> > > >
> > > > ----- Original Message ----- 
> > > > From: "Harald Mueller" <harald.m.mueller at bigfoot.com>
> > > > To: <antlr-interest at yahoogroups.com>
> > > > Sent: Tuesday, December 07, 2004 8:48 PM
> > > > Subject: Re: [antlr-interest] exceptions in the lexer
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > Hey, Just extend you user-defined exceptions from
RuntimeException
> > and
> > > > > > throw
> > > > > > them.
> > > > >
> > > > > He explicitly didn't want to do this - but I also do it (using a
> > > > > WrappingRuntimeException which I need at other places anyway (e.g.
> > for
> > > > the
> > > > > Runnable.run() method)).
> > > > >
> > > > > > You catch all your RuntimeExceptions don't you?
> > > > > > Remember OutOfMemoryException is not necessarly fatal.
> > > > >
> > > > > This is not an Exception, but an Error - you would never catch
this.
> > > > >
> > > > > Regards
> > > > > Harald M. Müller
> > > > >
> > > > > > matthew
> > > > > > ----- Original Message ----- 
> > > > > > From: "Paul J. Lucas" <pauljlucas at mac.com>
> > > > > > To: <antlr-interest at yahoogroups.com>
> > > > > > Sent: Tuesday, December 07, 2004 11:10 AM
> > > > > > Subject: Re: [antlr-interest] exceptions in the lexer
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > On Mon, 6 Dec 2004, Terence Parr wrote:
> > > > > > >
> > > > > > > > Are you familiar with the filter option on the lexer
grammar?
> > > > > > >
> > > > > > > Yes in the sense that I've read that bit of the documentation,
> > > > > > > but I've never used it.
> > > > > > >
> > > > > > > I don't want my entire lexer to be a filter since I need it to
> > > > > > > be a real lexer for a parser.
> > > > > > >
> > > > > > > My particular case at hand is dealing with pragmas that can
> > > > > > > appear anywhere comments can.  Since comments are most easily
> > > > > > > handled in the lexer, I handle pragmas there to for the same
> > > > > > > reason.  The problem is what to do if there's an error in a
> > > > > > > pragma.  The lexer can't throw user-defined exceptions.  (I
> > > > > > > might be able to work around it by hiding the real exception
> > > > > > > inside a Runtime exception, but that's ugly.
> > > > > > >
> > > > > > > - Paul
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Yahoo! Groups Links
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > -- 
> > > GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
> > > +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
> -- 
> GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
> +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>



 
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/

More information about the antlr-interest mailing list