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

[Christopher Brooks]

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
    >
    >
    >
    >
    >
    >  
    >
--------