FreeTDS Development Group

[Robert Boehne <robertb AT trdlnk.com>]

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