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
