Subject | Re: [Firebird-Architect] XSQLDA/XSQLVAR issues |
---|---|
Author | Jim Starkey |
Post date | 2005-01-13T23:45:07Z |
Dimitry Sibiryakov wrote:
build should do the trick. Linux is the default build in the buildgen
vulcan.build file. The proper way to handle it is set up a proper MinGW
platform in vulcan.build to handle any special switch or command
settings you may need. You may need to look at vulcan.build until
either your eyes cross or it makes sense. If the former, let me know
and I'll try to help.
we build in a function to register a callback with a known calling
sequence, we can the callback in your call to throw the actual
exception. The API implementation code doesn't care about the
mechanisms of the exception, just that a responsible adult does whatever
is required to make sure that it never returns from the exception callback.
I favor throwing an exception object as an open ended solution. I've
never liked the magic 20 words of status vector even though I was
responsible for it. What's the right number? Simple, there isn't a
right number.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
> Most likely I had to write 'one compiler at a time'. You couldI know next to nothing about MinGW, but I assume that tweak to Linux
>notice that my english is rather bad.
> If I'm wrong again, tell me, please, how I can compile Vulcan on
>Windows with MinGW (gcc 3.2).
>
>
build should do the trick. Linux is the default build in the buildgen
vulcan.build file. The proper way to handle it is set up a proper MinGW
platform in vulcan.build to handle any special switch or command
settings you may need. You may need to look at vulcan.build until
either your eyes cross or it makes sense. If the former, let me know
and I'll try to help.
>>Exceptions should be thrown as object, described above. ThatExceptions cross library boundaries are always going to be trouble. If
>>mechanism by which the API throw exception objects could include a
>>callback to perform the dirty deeds.
>>
>>
>
> Mind you that I didn't talk about throwing an exception. I was
>afraid of troubles in catching it. But because you said that public
>API won't throw exceptions, this shut up my objections.
>
>
we build in a function to register a callback with a known calling
sequence, we can the callback in your call to throw the actual
exception. The API implementation code doesn't care about the
mechanisms of the exception, just that a responsible adult does whatever
is required to make sure that it never returns from the exception callback.
I favor throwing an exception object as an open ended solution. I've
never liked the magic 20 words of status vector even though I was
responsible for it. What's the right number? Simple, there isn't a
right number.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376