On Mon, 3 Oct 2011, Dan Fandrich wrote:

> What's the point of a new error return code? There's nothing the
> application can do differently for CURLSHE_NOT_BUILT_IN as compared to
> CURLSHE_BAD_OPTION. And depending on the version of libcurl against which
> the application is linked, it could get either one of those in the same
> case.

It is part of my wish to better convey to applications/users what the actual
reason for a particular failure is, and in particular in a time when we offer
a bazillion different build options and the libcurl binaries people are
getting have a different set of features enabled and disabled. I introduced
the CURLE_NOT_BUILT_IN error code a while ago and changed a series of returns
to use that in a similar fashion.

In this particular case CURLSHE_BAD_OPTION tells the application that the
libcurl version doesn't support (or know of) the option. The libcurl you run
is simply too old or you passed in a funny option. If instead
CURLSHE_NOT_BUILT_IN is returned, you know that the distro/person who built
the library has not enabled or did actively disable the particular feature
you're trying to use - the libcurl you use clearly knows about the option.

In an ideal world, the differences could result in different treatment or
messages to the end users which could lead to less confusion. In a less ideal
world, I don't think it changes much.

It also helps us understand people's problems better when they report about
problems and they tell us what return code they get.

In my view, a new error code has very little affect to existing applications
and thus is very cheap to add. If this is a bad assumption, I'm willing to get
told and learn!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html