Subject | Re: [Firebird-Architect] Error Reporting in New API |
---|---|
Author | Dimitry Sibiryakov |
Post date | 2005-02-15T05:49:26Z |
On 14 Feb 2005 at 16:47, Jim Starkey wrote:
object? Ridiculous! ;-)
If you want object-oriented error handling - no problem. But hide
the object inside of library. Make every API function return one
single numeric return code which is FB_OK or a handle of an error
object that may be used in following calls of error-explaining
finctions like fb_interprete. No "first argument" at all! Full
extensibility because _you_ have a full control over the error
object.
Or even better: let API functions return GDSCODE for backward
compatibility, but introduce another function (say,
fb_get_last_error()) which, being called immediatelly after failed
call, returns the handle of the error object.
--
SY, Dimitry Sibiryakov.
>Here is a scheme that I think is worth discussing. The firstFull mess. Every API user has to implement its own error handling
>argument of all API functions is the address of a client-defined error
>receiving pseudo object.
object? Ridiculous! ;-)
If you want object-oriented error handling - no problem. But hide
the object inside of library. Make every API function return one
single numeric return code which is FB_OK or a handle of an error
object that may be used in following calls of error-explaining
finctions like fb_interprete. No "first argument" at all! Full
extensibility because _you_ have a full control over the error
object.
Or even better: let API functions return GDSCODE for backward
compatibility, but introduce another function (say,
fb_get_last_error()) which, being called immediatelly after failed
call, returns the handle of the error object.
--
SY, Dimitry Sibiryakov.