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

[stefan]

Citát David Ayers <d.ayers@inode.at>:

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

<snip>

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

Ok, then the "Ignore" button should be available only to developers. For users
there should be only "Report" button (see below).

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

True.

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

What about following redefinition of default exception handler dialog:

[Abort] - same as now
[Ignore] - log an error and return to the main runloop of the application
[Debug]/[Report] - launch GDB that will attach to the current application
(simple GDB switch with process id from NSProcessInfo), dump stack, write dump
to some file or pass it to another crash-watching process somehow and then just
abort. If GDB was running in some predefined terminal application, then keep
GDB running.

Stefan