[freetds] [PATCH] to remove exit statements from libct
Robert Boehne
robertb at trdlnk.com
Mon Mar 1 11:09:22 EST 2010
Frediano Ziglio wrote:
> 2010/2/28 David Dick <ddick at cpan.org>:
>
>> On 01/03/10 08:44, Christos Zoulas wrote:
>>
>>> On Mar 1, 8:18am, ddick at cpan.org (David Dick) wrote:
>>> -- Subject: Re: [freetds] [PATCH] to remove exit statements from libct
>>>
>>> | On 01/03/10 00:56, Frediano Ziglio wrote:
>>> |> Hi,
>>> |> some calls check internal behaviour witch should not raise (unless
>>> |> in situations where an exit is really necessary). However login and
>>> |> token should not exit as you detect correctly. I'll apply a modified
>>> |> version.
>>> |
>>> | So the remaining exits would designate a client programming error as
>>> | distinct from a server programming error / protocol error?
>>>
>>> Libraries should not exit; they should indicate the reason for the error,
>>> and generally avoid printing to stderr. The source of the error is really
>>> not relevant.
>>>
>> 100% agreed, i'm just trying to understand if any exit statements are
>> going to be left in the libct library and if so, why.
>>
>
> Well... I removed 3 of the exit you spot. Think about asserts, they
> exit application if they don't pass. I agree to remove any print
> statements and I removed a lot. There are however situations when even
> the os kernel "exit" (that is stop the entire system). In this case if
> an internal handler returns any values which are not coded to return
> some nasty things happen and I don't see any point in keeping going.
>
> freddy77
There are a lot of problems with calling exit() from a library
(similarly with printing to stdout) in more dynamic systems with plug-in
architecture, i.e. languages like python or applications like Apache.
Calling exit() will cause the process to exit, and that behavior can't
reasonably be changed per library being called.
Any library should report errors it encounters, and in C this requires
the caller to check error codes. Languages with exceptions make this a
bit easier by raising them and allowing the caller to handle them - or
not. Calling exit() is just not flexible enough to be helpful in these
situations, it ends up being more harmful than helpful.
When libct finds itself in an error state where it can no longer
function, applications may still function perfectly - perhaps by
displaying a dynamic web page that informs the user that the apache
plugin can't connect to the database. If apache exits at he point where
an error is detected this is simply not possible.
If I had ever noticed the exit() calls myself, I would have submitted
this patch a long time ago :)
Robert Boehne
More information about the FreeTDS
mailing list