You may be more interested in why something failed than just that it failed.
An error mechanism should play nicely with the status vector to expose as much -- or as little as the user needs. Sometimes an error code is enough, sometimes a full formatted compound message is required. But a second call to pick up the "last" error would probably make almost every one happy. > On Aug 11, 2014, at 4:14 PM, Tom Coleman <tcole...@autowares.com> wrote: > > > >> On Aug 11, 2014, at 2:40 PM, Adriano dos Santos Fernandes wrote: >> >>> On 11/08/2014 15:29, Tom Coleman wrote: >>> >>> I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL. >>> >>> There is never any case where I would want to see std:exception. >>> >>> Could it be time to start thinking about burying this idea that is looking >>> more and more like a sacred cow? >> Then the chances of not wanting a FbException (not inherited from >> std::exception) are also very high. >> >> This is what polices are for. You replace the parts which the library >> author does not known how you want to be. >> >> One of the policies would be a DoNotThrowPolice, which will require you >> to check the IStatus. > > The interfaces all rely on returned status codes. At the interface level > all I need is some indication of pass/fail, and some indication of why the > operation failed. > > At the client level I have no interest in debugging the database. > > > > > > > > > > ------------------------------------------------------------------------------ > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
