On Aug 11, 2014, at 12:06 PM, Lester Caine wrote:

> On 11/08/14 12:53, Alex Peshkoff wrote:
>>> IBPP can
>>>> still act as a high-level C++ wrapper, FIBPlus/FireDAC/whatever would
>>>> act the same for Delphi, etc. They just need to be ported to the new
>>>> core API (whatever it will be).
>> I agree with this is POV 100%.
> 
> I've been following the debate on 'new interface' and to be honest I
> still don't understand where the problem is. Having used IBObjects on
> legacy projects, that has not been used for a long time as I am now
> reliant on PHP and Jaybird these days to pull results from Firebird.
> Neither of these need an internal interface weight down by C++ and I'm
> sure a lot of power users are in the same boat? C++ is a layer on top of
> the connection to the database and I'm sure if I need to revert to that
> I'd be looking to IBObjects again, but certainly windows will not be
> featuring in that which ever way I go.

On Aug 11, 2014, at 2:08 PM, Adriano dos Santos Fernandes wrote:

> No one is telling to pass exceptions across modules, it's quite the
> contrary. The generated impl. wrapper is going to guarantee that not
> happens in the Firebird code.
> 
> But an (client) application wants to generate exception when accessing
> the API, and we do not know in advance what's the good classes for each
> project.
> 
> Some may use like Firebird, an Exception not inherited, others wants
> std::exception, a Qt-based project would want another one...


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?



------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to