FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: liam AT inodes.org
> Sent: Thursday, June 30, 2005 2:29 AM
> 
> On Tue, Jun 28, 2005 at 11:16:23AM +0200, ZIGLIO, Frediano, VF-IT
> wrote:
> > Mmmm... perhaps we should call tds_cancel/exit inside error
> > handler...  only dblib require INT_CANCEL/INT_EXIT.
> 
> Yes, this is what I tried to suggest previously. I have a real
> problem with any library calling exit(). Though, I understand the
> requirement for dblib compatibility, etc. I agree that it should
> be done solely where necessary for dblib only.

Hi Liam, 

Glad to know you're watching.  I'd like to get this right.  :-)

The idea is that you, as the application programmer, control whether or
not the library calls exit(3) through your choice of return code in your
error handler.  You return INT_CANCEL except for SYBETIME (for which you
return INT_TIMEOUT).  Your calling function sees its call to, say,
dbresults() as FAIL, and the dbproc remains useable.  

Let's say your application should never encounter a "results pending"
error, and that proceeding from there would lead to data corruption.
You could code your error handler to return INT_EXIT in that case only,
aborting the app but preserving the data integrity.  You might not want
to do that, but it's supposed to be your choice.  

Frediano's question is a little more technical, I think.  He's musing
how the glue function -- the one called by libtds that calls the user's
handler -- should deal with the handler's return code.  Should it call
libtds functions to effect the user's intent, or should it return a code
for libtds to interpret?  

I think it's easier, clearer, and more consistent if the db-lib doesn't
call its caller.  The libtds function that invokes the handler is going
to have to learn either a) what to do, or b) what was done and what to
do.  Because the set of "what to do" overlaps the needs of different
libraries, and because libtds is in a better position to know its state
than is db-lib, I think (a) is the better answer.  It will yield less
code with fewer branches.  

Regards, 

--jkl 


-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s) 
named
above. If you are not the intended recipient, or an employee or agent 
responsible
for delivering this message to the intended recipient, any review, 
dissemination,
distribution or duplication of this communication is strictly prohibited. If 
you are
not the intended recipient, please contact the sender immediately by reply 
e-mail
and destroy all copies of the original message. Please note that we do not 
accept
account orders and/or instructions by e-mail, and therefore will not be 
responsible
for carrying out such orders and/or instructions.  If you, as the intended 
recipient
of this message, the purpose of which is to inform and update our clients, 
prospects
and consultants of developments relating to our services and products, would 
not
like to receive further e-mail correspondence from the sender, please "reply" 
to the
sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New 
York,
NY 10105.