Skip to Content.
Sympa Menu

freetds - Re: [freetds] FreeTDS, C++, and Exceptions

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Lenon Kitchens <lenonk AT sanctuary.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] FreeTDS, C++, and Exceptions
  • Date: Sun, 18 Jun 2006 12:09:37 -0400

Thanks a lot for you concise and informative answer. I'll try modifying my handlers the way you suggest and see if it helps. I'll also go back to my previous design of allocating a new exception object from the handlers and throwing it from my library after the freetds call.

Thanks again!

L

James K. Lowden wrote:
Lenon Kitchens wrote:
It wasn't until recently that I noticed a problem with the FreeTDS part of my implementation. I have installed error and message handlers using

dberrhandle() and dbmsghandle(). At the end of each of these functions,

I throw an exception like so:

throw DBLibException(EGENERAL_EXCEPTION, err.str());

The "err" string is obviously filled out during the function. The problem is that for some reason, this exception goes completely uncaught

and results in terminate() being called.

I know from first-hand experience you're not the first person to make that
mistake. ;-)

You must not throw an exception in your handler function. Think about (or
examine) the state of the call stack when the handler has control. In
effect, your handler is more an extension to db-lib than a part of your
application. It is called by a C library and so demands C semantics.
http://manuals.sybase.com:80/onlinebooks/group-cnarc/cng1110e/dblib/@ebt-link;pt=24258?target=%25N%15_16564_START_RESTART_N%25

The *only* vehicle your handler has for conveying information to db-lib is
through the return code. If you don't want the library ever to call
abort(3), make sure you never suggest such a thing via the return code. If you code the handler correctly and db-lib still exits on you, that
would be a bug and we will fix it.
(There. You read it here first. A free software guarantee.)
In your test program, sybErrHandler returns 0 sometimes. It can't do
that. To continue working, it must return INT_CANCEL except for SYBETIME.
For SYBETIME, you have a choice between INT_CONTINUE and INT_TIMEOUT. (I'm not perfectly sure timeouts work, but I think they do.) Conversely,
sybMsgHandler sometimes returns INT_CONTINUE. It may not. It must return
0, ever and always.
Of course, your handler can set a flag that your library routinely checks
to see if it's time to throw an exception. Your stack you can unwind;
just don't muck with db-lib's if you want it to play nice, OK?
I suggest you take a closer look at the docs, rewrite your handlers, and
see if you then still have unexpected terminations.
--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds





Archive powered by MHonArc 2.6.24.

Top of Page