FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2010/3/1 Christos Zoulas <christos AT zoulas.com>:
> On Mar 1,  4:53pm, freddy77 AT gmail.com (Frediano Ziglio) wrote:
> -- Subject: Re: [freetds] [PATCH] to remove exit statements from libct
>
> | 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.
>
> Well, asserts use usually no-ops in non-debug builds, and do
> extensive consistency tests in debug builds. So it is up to the
> user to build a debug version of the library or a production one.
> And the kernel panics in many situations where it detects that
> continuing might cause more damage (for example in the filesystem
> code when what it finds on the disk is not what it expects to find),
> but usually the panic calls are the result of lazy programming (I
> don't want to figure out what I need to do to cleanup; the caller
> does not know what to do if I fail). In the past there have been
> many efforts to reduce the number of panic calls in the Unix kernel
> to make it more reliable. Unless I am missing something, I see no
> reason for libct to ever need to call exit(2) since in the majority
> of scenarios the application should be able to recover by cleaning
> up all pending state, and re-initializing the connection. Of course
> if libct determines that there is no way for the application to recover
> perhaps it should abort(3) instead.
>
> christos

Yes, you are right, in these cases abort is better than exit.
I noted that last conditions from Dick patch (error handler return
code check) was already checked by asserts so I remove exit code.

freddy77