[kepler-dev] Abort/Retry/Error Stacktrace window

Kevin Ruland kruland at ku.edu
Fri Dec 16 12:30:47 PST 2005


Christopher,

A number of people have come out saying that java copped out by allowing
unchecked exceptions.  The C++ community has it even worse because all
exceptions are unchecked and the raises clause essentially does
nothing.  The "no throw" clause was actually very nice addition and is
quite necessary.  Alas, it is a sorry confused world we live in.

I very much like your convention of using RuntimeException as meaning a
testable precondition.  This is the first time I've every seen this idea.

Really, where I was going was define some base type all of whose
descendents could force an application shutdown.  I thought Error or
RuntimeException were natural candidates, but definitely defer to you
insight since you have thought about this much more than I have. 

<aside>
I'm puzzled by the LinkageError and your handling of it.  If indeed it
means, "look someplace else", the program would have to know where else
to look - or propt the user to select file/directory or something like
that.  But I do see the benefit of allowing the user the opportunity to
save his work -- however disfunctional the work is until the proper dll
can be found.
</aside>

Perhaps we are not thinking about this correctly.  The only time, that I
can think of, where such a painful abort is necessary is during
application startup.  Maybe there should be a different MessageHandler
installed during application startup vs application running?  This
combined with some class of error which requires abort could be the
right direction.

Kevin

Christopher Brooks wrote:

>Hi Kevin,
>Umm, there is no option #3?  Do you prefer 1, 2 or some other option?
>
>Do you mean that option #3 is to treat java.lang.Error separately?
>
>The problem is that OutOfMemoryError is a java.lang.Error, and usually
>it means "Die", but sometimes it means "Don't open that really big
>file".  LinkageError is a java.lang.Error that occurs with linking in
>a JNI shared object fails.  However, getting a LinkageError sometimes
>means that we need to look elsewhere for the shared object.
>
>The upshot is that I don't think we can just say all java.lang.Errors
>are bad and that the process should die asap without prompting the
>user to either not exit or at least giving them a chance to save
>buffers etc.
>
>I've fixed a ton of bugs where we were catching Exception but instead
>needed to catch Throwable (the baseclass to Exception and Error).
>
>Can you give me an example of an exception that really should always
>exit the process?  That would help me wrap my brain around this.
>
>I guess I'd be most comfortable with a window that allowed the user to
>exit or not exit, but this defeats the purpose, since the user would
>probably just click cancel and proceed.  For example, the errors I
>reported last night were appearing in the start up window, not in a
>dialog and I just ignored them for several days.
>
>
>BTW - The Java Tutorial talks about "Unchecked Exceptions The
>Controversy" in
>http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
>
>Just for laughs, I've also included a section of the Ptolemy Style
>guide below
>http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIlatest/ptII/doc/coding/style.htm
>--start--
>Exceptions
>
>A number of exceptions are provided in the ptolemy.kernel.util
>package. Use these exceptions when possible because they provide
>convenient constructor arguments of type Nameable that identify the
>source of the exception by name in a consistent way.
>
>A key decision you need to make is whether to use a compile-time
>exception or a run-time exception. A run-time exception is one that
>implements the RuntimeException interface. Run-time exceptions are
>more convenient in that they do not need to be explicitly declared by
>methods that throw them. However, this can have the effect of masking
>problems in the code.
>
>The convention we follow is that a run-time exception is acceptable
>only if the cause of the exception can be tested for prior to calling
>the method. This is called a testable precondition. For example, if a
>particular method will fail if the argument is negative, and this fact
>is documented, then the method can throw a run-time exception if the
>argument is negative. On the other hand, consider a method that takes
>a string argument and evaluates it as an expression. The expression
>may be malformed, in which case an exception will be thrown. Can this
>be a run-time exception? No, because to determine whether the
>expression is malformed, you really need to invoke the
>evaluator. Making this a compile-time exception forces the caller to
>explicitly deal with the exception, or to declare that it too throws
>the same exception. In general, we prefer to use compile-time
>exceptions wherever possible.
>
>When throwing an exception, the detail message should be a complete
>sentence that includes a string that fully describes what caused the
>exception. For example
>
>
>throw IllegalActionException(this,
>    "Cannot append an object of type: "
>    + obj.getClass().getName() + " because "
>    + "it does not implement Cloneable.");
>
>Note that the exception not only gives a way to identify the objects
>that caused the exception, but also why the exception occurred. There
>is no need to include in the message an identification of the "this"
>object passed as the first argument to the exception constructor. That
>object will be identified when the exception is reported to the user.
>
>If an exception is caught, be sure to use exception chaining to
>include the original exception. For example:
>
> 
>
>String fileName = foo();
>
>try {
>
>     // Try to open the file
>
>} catch (IOException ex) {
>
>   throw new IllegalActionException(this, ex,
>        "Failed to open '" + fileName + "'");
>}
>--end--
>
>_Christopher
>
>--------
>
>    
>    Christopher,
>    
>    The option I like the best is #3.
>    
>    What about treating classes exending java.lang.Error seperately.  This
>    hierarchy includes those nasty unrecoverable problems like
>    OutOfMemoryError and the like.  They are also unchecked so they do not
>    need to be declared.
>    
>    Kevin
>    
>    
>    Christopher Brooks wrote:
>    
>    >Hi Kevin,
>    >You wrote:
>    >
>    >  
>    >
>    >>Which brings me to something you probably know about.  Ptolemy likes
>    >>to pop up a little "display stack trace" dialog.  The problem with
>    >>this dialog is that after clicking on either buttons, the base
>    >>window opens.  To a naieve user who is accostomed to random mishaps
>    >>in windows, they might not be aware that the system is
>    >>nonfunctional.  Is it possible to have some classes of exceptions
>    >>(such as RuntimeException) which go past that dialog and force the
>    >>application to abort?  Or better yet, presents a different dialog
>    >>which then ends up aborting.
>    >>    
>    >>
>    >
>    >I'm always really nervous about forcing a quit on the application,
>    >since we run the risk of losing user data etc.
>    >
>    >I can see two ways to implement what you are proposing:
>    >
>    >1) Modify ptolemy/util/MessageHandler.java so that it has
>    >a errorAndExit() method that would do the right thing.
>    >I'd prefer the message to be really clear that there is a problem 
>    >and offer the user the option of not exiting.  However, it might
>    >be worth just putting up the error and then the next click would 
>    >call System.exit().
>    >
>    >ptolemy/gui/GraphicalMessageHandler.java would need to be extended
>    >to have the right buttons.
>    >
>    >Be warned that I've run in to problems at start up where not all of
>    >the configuration is functional and one want to put up an error
>    >message but there is not enough configuration to really do this.
>    >
>    >2) Create a TerminateJavaException (or something) that is meant to
>    >terminate the Java process.  MessageHandler and
>    >GraphicalMessageHandler would need to check for this exception, much
>    >like how they check for CancelException.
>    >
>    >It would seem that putting this work in the Ptolemy tree would the
>    >natural location.  I believe Edward would have some input on the
>    >design.
>    >
>    >_Christopher
>    >
>    >
>    >
>    >
>    >
>    >  
>    >
>--------
>  
>


More information about the Kepler-dev mailing list