Subject | Re: [IBO] IBO & Application.HandleException |
---|---|
Author | Martijn Tonies |
Post date | 2006-10-17T11:42:34Z |
> > The thing is -- the IBO code is called from within a library thatI kinda have been thinking about this as a workaround. I guess all
> should
> > never raise a dialog, but it should return the error codes.
> >
> > Now, if IBO raises a dialog by calling Application.HandleException
> > (which does ShowException by default), this is wrong.
> >
> > If I use the event handler to "eat" the exception, I cannot return
> an
> > error code, cause from the calling code, it looks like there WAS no
> > exception (= eaten).
> >
> > So, I would like to have IBO leaving all exception handling to the
> calling
> > application, not do it yourself (that is, for exception that you
> don't know
> > how to handle).
> >
> > I've been looking through the code and there are several calls to
> > Application.HandleException -> some of them could make sense, as
> they
> > are used in methods that explicitly use GUI items (eg:
> CommitWithConfirm
> > (or what was it)). For others, however, it does not make sense at
> all.
> > eg, in a Sys<something>Commit, IBO cannot know if it's being used
> by
> > a GUI application or something else, so it should never ever
> expect to
> > use a GUI and act accordingly. But given that I do not fully know
> the
> > internals and some of these calls to HandleException are in a
> loop, I expect
> > that you figured the code could continue after the call to
> HandleException
> > and the user has clicked the dialog. IMO, this needs to be changed.
> >
> >
>
> What if your Application exception handler just stored the data from
> the error object (or better, a reference to the object itself) in a
> list and then returned (as though the regular error dialog had been
> shown and the user clicked OK). Then, after your library regains
> control, it can look at this list and do what it needs to do.
>
> I'd bet only the first object would be of interest because of
> cascades, but at least you can then return its error data without
> having to invoke a GUI.
my calls would have to check for a global stored exception object
after that and return an error code accordingly.
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com