On Friday 29 June 2018 02:29 PM, Daniel Stenberg wrote:
> 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?

The problem is that I cannot simulate all error conditions. And as of
now, I do not know what are the possible errors that might occur. The
best I can do now, is to simulate a few conditions and then throw in a
general error message.
It would have been nice to look at the error code list for say SMTP and
put in a switch case to handle the errors.
>
> 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.
Agreed. This is not a problem.

>> 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.

Ok. I hope the old error code values remain same and do not change. If
new ones are added in the future releases, a general error can be thrown.

Thanks,
-Deven

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-06-29