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

[Christopher Brooks]

Hi Kevin,
I think Edward (or possible Jorn Janneck or John Reekie) are the
ones behind the testable precondition notion.  I think this extends
from other ideas, I want to say Eiffel or Haskell but I'm guessing.

About Linkage errors, I don't think they are always fatal errors
because it could just mean that there was a problem building a shared
object.  For example, the Viptos (the Ptolemy/PtinyOS interface)
creates shared objects at model runtime that interface to the C based
PtinyOS code.  If there is a problem with the shared object, you might
see a LinkageError.  Usually, this is not fatal, it just means there
was a small problem somewhere that the user would like to try again.

Currently, our method of handling start up errors is pretty rough.
I'll think about better ways to handle this.

Defining a FatalError is one possibility, but it needs to be used
to save the user situations that could cause great harm.  I'm nervous
about it.  I can see putting a bunch of initialization code in 
a try block and saying that if an exception is thrown, then we pop
up a message and stop.  However, sometimes things that seem fatal are
not fatal.

I dunno.

BTW - In my mind, given choice of 1 or 2; option 3, the option that
was not mentioned, is always a possibility and often the right
choice. :-)

_Christopher

--------

    
    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/styl
   e.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
    >    >
    >    >
    >    >
    >    >
    >    >
    >    >  
    >    >
    >--------
    >  
    >
--------