Hello Jason,

> > > What kind of access to the original calling code do you require?
> >
> > The thing is -- the IBO code is called from within a library that should
> > never raise a dialog, but it should return the error codes.
>
> I presume you are in control of that library and as such are you not in
> control of the Application instance in that library?

Yes. (btw, here, you are already assuming there IS an TApplication
instance, which, IMO, you shouldn't.)

> You should do the plumbing in your library that your application requires.
>
> Yes, by default a dialog box may appear as a result of an exception, but

it

> is your responsibility as a programmer to hook in and provide more
> appropriate behavior if the default is unsatisfactory.
>
> As I see it I have no other hook to tie into other than the
> Application.HandleException hook. Please tell me if I am failing to see a
> more appropriate alternative.

The problem is that I _have_ to hook into this as a last resort. I cannot
call something in IBO, put an exception handler around it and handle
the exception. Instead, IBO calls Application.HandleException. This might
be fine in a normal application, but for a component set, I find this a bit
weird.

> > 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).
>
> Exceptions are not automatically propagated to the application that calls
> the library. As I recall things get pretty messed up if an exception
> remains unhandled in a library.

Yes, I know that -- this isn't the idea what I'm trying to get across.

> I believe there is rather benign handling of the Abort method built in to
> the VCL that would avoid problems that otherwise would result.
>
> > 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.
>
> The only safe thing I can think of is to have code along the lines of:
>
> If IsLibrary then
> SysUtils.Abort
> else
> Application.HandleException();
>
>
> Another possibility is to put a HandleException method on the TIB_Session
> class which will allow a programmer to easily override all of IBO's
> exception handling and it would default to use the
> Application.HandleException of another hook were not provided.

IMO, the Application.OnException hook is a work-around for the actual
problem: IBO shouldn't assume Application and should have exception
handling in it's methods, so the code that calls these methods can put
exception
handling blocks around them, where they should be in the first place.

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