Re: libcurl smtp error list?
Date: Fri, 29 Jun 2018 16:56:42 +0530
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
> 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
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.
Received on 2018-06-29