FreeTDS Development Group

[Marc Abramowitz <msabramo AT gmail.com>]

> I like tdserror. I don't like printf or an additional option. Printf
cause it
> can go nowhere or in dangerous places, an additional option cause it force
> different users to recompile the same library with different options
based on
> the usage. Using options to deal with debugging or different system
> configuration is fine but this option would be ok for an application but
not
> for a library used in different places.

> What I would do, also suggested by James is something strong. If you pass
a
> wrong option just try to notify upper layer (as tdserror does) and do not
> connect! Surely user will fix the configuration! Of course should be
> documented in the version changelog and UG. I'll try to write a partial,
not
> that tested patch. Does it sound reasonable?

I had another branch where I did something like that actually. I just
cleaned it up and made another merge request.

https://gitorious.org/freetds/freetds/merge_requests/18

If that resembles or is useful towards implementing what you suggested,
feel free to use it, or if it's different, you can go ahead and do your own
thing. The idea certainly sounds reasonable.


On Mon, Oct 21, 2013 at 4:51 PM, Frediano Ziglio <freddy77 AT gmail.com> wrote:

> I like tdserror. I don't like printf or an additional option. Printf cause
> it can go nowhere or in dangerous places, an additional option cause it
> force different users to recompile the same library with different options
> based on the usage. Using options to deal with debugging or different
> system configuration is fine but this option would be ok for an application
> but not for a library used in different places.
>
> What I would do, also suggested by James is something strong. If you pass
> a wrong option just try to notify upper layer (as tdserror does) and do not
> connect! Surely user will fix the configuration! Of course should be
> documented in the version changelog and UG. I'll try to write a partial,
> not that tested patch. Does it sound reasonable?
>
> Ps: we have still to sort out the Travis patch. Does the configuration
> file need to be in the main directory? Cannot you change the name? What
> happen if another developers want to use Travis too?
>
> Frediano Ziglio
>
> Il giorno 21/ott/2013, alle ore 21:48, Marc Abramowitz <msabramo AT gmail.com>
> ha scritto:
>
> > That makes sense.
> >
> > OK, I took another stab at creating a louder notification when the
> > encryption setting is incorrect:
> >
> > *https://gitorious.org/freetds/freetds/merge_requests/16* ("Improve
> > handling of invalid encryption setting")
> >
> > The goal here is to make it much more noticeable when there is an invalid
> > encryption setting. I do this by:
> >
> >   - calling tdserror with a new error code (TDSECONF = 20214 = "Local
> >   configuration error")
> >   - print a message to stderr in case in case someone is looking there
> >   - exiting the process if the ENABLE_EXIT_ON_INVALID_CONFIG is defined
> >   (defined by passing --enable-exit-on-invalid-config to./configure).
> >
> >
> >
> > On Sat, Oct 19, 2013 at 11:49 AM, James K. Lowden <jklowden AT freetds.org
> >wrote:
> >
> >> On Sat, 19 Oct 2013 09:48:12 -0700
> >> Marc Abramowitz <msabramo AT gmail.com> wrote:
> >>
> >>>>> Merge request to make an invalid encryption setting a fatal error:
> >>>>> https://gitorious.org/freetds/freetds/merge_requests/10
> >>>>
> >>>> Ouch indeed.  I think the next release of FreeTDS should probably
> >>>> reject all incorrect configurations, both invalid keywords and
> >>>> out-of-range values.  Diagnosing configuration errors is easier if
> >>>> the error is obvious, and the remedy is simple.
> >>>
> >>> Freddy pointed out that my merge request wasn't acceptable because
> >>> printing to stderr and exit aren't appropriate for a library.
> >> ...
> >>> Is there some middle ground - some way of indicating a config error
> >>> (esp. a serious config error like an invalid encryption setting) that
> >>> is very noticeable but doesn't overstep what a library should do?
> >>
> >> The Right Way is to hook into the error handler.  Add something like
> >> this to the table in sybdb.h:
> >>
> >> #define SYBECONF         2501   /* local configuration error */
> >>
> >> and to the dblib.c::dblib_error_messages table
> >>
> >> and invoke that error with tdserror or dbperror.
> >>
> >> It's not obvious to me that printing to standard error and exiting is
> >> all that bad, though.
> >>
> >> In general, there are two kinds of errors:
> >>
> >> 1.  logic errors, caused by the programmer getting something wrong.
> >> Examples include off-by-one errors and failure to check for a NULL
> >> pointer.  These kinds of problems can and do cause the library to
> >> exit via  e.g. assert(3).  There is no point in continuing, because the
> >> program has reached an "impossible" state that the program did not
> >> anticipate and thus cannot handle.
> >>
> >> 2.  runtime errors, caused by invalid user input or dynamic failures
> >> such as network disconnection or the server not responding.  These
> >> should always return an error to the user, who is the only person in a
> >> position to deal with it.
> >>
> >> Is an invalid configuration a logic or runtime error?  is the
> >> administrator a programmer or a user?
> >>
> >> I would say the configuration file is more like program text.  It is
> >> static data isolated from the program in such a way that it can be
> >> modified without requiring recompilation.  The very first time it is
> >> read -- compiled, if you will -- it will be validated.  If it is
> >> invalid, the library exits.  Once the configuration is valid, no amount
> >> of other invalid input will cause it to become invalid.
> >>
> >> Printing to stderr is unfortunately not robust, because some
> >> applications will not have that descriptor open.  Invoking the error
> >> handler is is more general, but will go unseen if the application
> >> doesn't install and error handler. On the other hand, the problem can be
> >> instantantly diagnosed by using any command-line tool such as tsql.
> >>
> >> So, IMO printing to stderr and exiting is fine, and invoking the error
> >> handler is in some ways friendlier (perhaps in addition to writing to
> >> stderr).  Exiting is OK, too, even if it does force the admin to clean
> >> up errors that might otherwise be innocuous.
> >>
> >> HTH.
> >>
> >> --jkl
> >> _______________________________________________
> >> FreeTDS mailing list
> >> FreeTDS AT lists.ibiblio.org
> >> http://lists.ibiblio.org/mailman/listinfo/freetds
> >>
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>