On Fri, 29 Jun 2018, Deven wrote:

>> A lot of libcurl code is generic for all/many protocols and we have a
>> generic error code handling all over. It not only makes it very hard to
>> figure out exactly what error codes that can be returned for what
>> protocols, it also makes it a fairly "unstable" situation in the way that
>> we may change internals for the next release and then change the possible
>> returns codes.

> This makes testing really difficult, unless you know the internals of
> libcurl.

You mean to test for specific return codes and the risk that a future version
might in fact return a different one?

I don't think that is normally a huge problem. It's like when we fix a problem
and something changes. If we return a different error in the future, it is
because the dfifferent error is the more correct one.

We can't guarantee that error paths will be the same forever.

> And if the return codes change across releases, then handling errors (to
> provide error feedback to the user) across different libcurl versions
> becomes impossible.

So if we can't fix our code to fix problems or improve things, what do you
suggest we do?

I think you're overstating this problem. Maybe because I made it sound as if
the return codes change frequently when in reality they are not.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html