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
