> > >> > Mind you though - Firebird isn't even able to sandbox a misbehaving
> > >> > UDF currently :-/ ... The engine seems to restart even after minor
> > >> > errors.
> > >>
> > >> Well, that's to be expected, right? UDF's are written in an "unsafe
> > >> langugage" (C, Delphi) and run in the same process space as FB. Same
> > >> DLL's, most browser plugins, etc.
> > >
> > > But, even with a divide by zero exception! ... :-/
> > Does this means that calls to UDF function from the server code are not
> > wrapped in a SEH bracket (Win32) or even a C++ catch-all exception ? It
> > would allow the server to recover and emit an error instead of going
> I'm not sure - (didn't check the code). From an access violation, for
> example, the server crashes/shuts down, which pretty much makes
> sense (you don't know what happened in the server memory/code
> space). But for a divide by zero, raising an exception would be good
> enough I guess.
> Can someone else comment on this?
Yes, may be it would have a sense to make UDF sandbox for pretty much
situations. If it is clearly that some error in UDF function is critical for
but not crirical for server itself why not inform server about bad result of
function (may be with
appended error message) - it will abort transaction but not the server.
> With regards,
> Martijn Tonies
> Database Workbench - the developer tool for InterBase & Firebird
> Upscene Productions