Re: -gui Uncaught Exception Handler (Was: Getting UTF-8 value of string occasionally fails)

[David Ayers]

Stefan Urbanek wrote:

> On Wed, 2004-10-13 at 15:07 +0200, Alexander Malmberg wrote:
> 
>>David Ayers wrote:
>>[snip]
>>
>>>Lest I here objections, I'll prepare a patch to address this somehow.
>>>Please let my know you preferences.
>>
>>While this is _amazingly_ ugly, the fact remains that it works 
>>surprisingly often, so I'd rather keep the button.
> 

The problem is that it is unclear what "it works" really means.

> 
> I agree. Removing that button is similar to changing GCC to stop right
> after first erroneous line found ignoring other errors. Yes, sometimes
> other errors are caused by the first line, but usualy you can get a
> picture of most of the errors on one compilation. Same for applications:
> you can found several errors on one compilation+run.
> 
> I would rather suggest to add note to the doucumentation, that
> developers should be aware that it is possible to return from exception.
> Suggested behaviour would be: return nil, ignore operation, try to
> continue with restrictions, etc.
> 
> 
>>If there are users who expect it to work all the time, perhaps we should 
>>change the label. How about "Crash later"?

The analogy to GCC doesn't hold for several reasons.  First the uncaught
exception is not comparable to error message of GCC when it actually is
handling an error of user input (the source file).  It compares a lot
better to an ICE (internal compiler error) which does indeed abort
immediately.  But even when it does handle the user input error, it
insures that no bogus output (read executable) is generated.

It's also not simply a matter of crashing later.  In fact the case I was
chasing was saving a .eomodeld file at a write protected location.  Now
in this case it wasn't dramatic as the initial write already failed.
But what if the problem is something else and the files have already
been partially saved?  And the user ignores the exception and the
application continues thinking the file on disk is up-to-date.

So, when an Application is editing a document, a gorm file, an inbox or
a database, this ignored exception could very well lead to corrupted
files/database inconsistencies.

In my view it is the applications responsibility to catch the exception
and verify it's internal state before allowing the user to continue.  (I
can see that during development this can be viewed as a feature, but not
for released code.)  If the application doesn't have internal state and
doesn't manage documents, then it is free to simply ignore the
exception.  But it should do so explicitly with an exception handler.
Not by virtue of the -gui uncaught exception handler.

<sarcasm>
OTOH, if you get paid for support (like me), and you like to dig into
corrupt files to see if you can save any information, I can see that
this is indeed a feature :-)
</sarcasm>

Cheers,
David