Re: curl errors to symbol string functions? was Re: libcurl smtp error list?
Richard Gray wrote: we can add the symbol XYZ037 Frambastat could not be initialized, errno = 226 (EADDRINUSE) which is more meaningful, particularly given that the higher errno values are different on different platforms. We could use strerror(), but it's messages are much longer and sometimes not quite right in the context of an error we get. One would need to generate such an errno_table[] for all supported (and unforeseen) compilers/targets. Since most 'Ex' values are not unique among targets. How can libcurl do that best? An included errno-file for each target? -- --gv --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libcurl smtp error list?
On Friday 29 June 2018 03:23 PM, Gisle Vanem wrote: Deven wrote: This makes testing really difficult, unless you know the internals of libcurl. And if the return codes change across releases, then handling errors (to provide error feedback to the user) across different libcurl versions becomes impossible. I cannot help you with this problem. But if you want a full list of 'CURLE_x' and 'CURLOPT_x' values a priori or within your program, I've cooked up this GNU-makefile that generates such a list: https://gist.github.com/gvanem/4290a4c74ac75983928502303cb4c0c2 Tested on Windows using MinGW and MSVC only. I'd be interested to hear if this mk-opt-err-list.mak works on non-Windows too. Thanks :). -Deven --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libcurl smtp error list?
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
Re: libcurl smtp error list?
On Fri, 29 Jun 2018, Gisle Vanem wrote: grepping the header file could be to extract the symbols from docs/libcurl/symbols-in-versions instead, which is sort of "pre-grepped" Can we trust your docs matches the reality? :-) (I assume 'symbols-in-versions' is *non* generated). We can be pretty sure of this since we have tests that verify that all public symbols in the header file is also listed in the symbols-in-versions file (test 1119), so all pull-requests and commits on github will have to make sure those are in sync to get the green checkmark! -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libcurl smtp error list?
Daniel Stenberg wrote: I've cooked up this GNU-makefile that generates such a list: https://gist.github.com/gvanem/4290a4c74ac75983928502303cb4c0c2 Cool. I didn't try it yet, but wanted to mention that an alternative to grepping the header file could be to extract the symbols from docs/libcurl/symbols-in-versions instead, which is sort of "pre-grepped" (with the "obsolete" and "_*last" symbols already filtered out) =) Can we trust your docs matches the reality? :-) (I assume 'symbols-in-versions' is *non* generated). But I was thinking of using 'docs/libcurl/symbols-in-versions' or 'docs/libcurl/symbols.pl' to create an extra column like this: Idx CURLOPT_xvalue: arg type raw value Added in ver == 0: CURLOPT_ABSTRACT_UNIX_SOCKET-> 264: object/string 102647.53.0 1: CURLOPT_ACCEPTTIMEOUT_MS-> 212: long 2127.24.0 -- --gv --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libcurl smtp error list?
On Fri, 29 Jun 2018, Gisle Vanem wrote: I've cooked up this GNU-makefile that generates such a list: https://gist.github.com/gvanem/4290a4c74ac75983928502303cb4c0c2 Cool. I didn't try it yet, but wanted to mention that an alternative to grepping the header file could be to extract the symbols from docs/libcurl/symbols-in-versions instead, which is sort of "pre-grepped" (with the "obsolete" and "_*last" symbols already filtered out) =) -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libcurl smtp error list?
Deven wrote: This makes testing really difficult, unless you know the internals of libcurl. And if the return codes change across releases, then handling errors (to provide error feedback to the user) across different libcurl versions becomes impossible. I cannot help you with this problem. But if you want a full list of 'CURLE_x' and 'CURLOPT_x' values a priori or within your program, I've cooked up this GNU-makefile that generates such a list: https://gist.github.com/gvanem/4290a4c74ac75983928502303cb4c0c2 Tested on Windows using MinGW and MSVC only. I'd be interested to hear if this mk-opt-err-list.mak works on non-Windows too. -- --gv --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libcurl smtp error list?
On 29 Jun 2018, at 05:14, Deven wrote: > I want to handle errors from curl_easy_perform() and provide a feedback to > the users on what went wrong (SMTP server not correct, authentication > failure, network not reachable, etc.). > The errors mentioned in curl.h header are quite general (at least to me). Is > there a list of protocol specific errors (in this case SMTP)? I've only used them with HTTP so have no direct experience whether the latter in particular gives what you need for SMTP, but it seems like perhaps you are looking for CURLINFO_OS_ERRNO (for network not reachable etc) and CURLINFO_RESPONSE_CODE (for SMTP response codes)? See https://curl.haxx.se/libcurl/c/CURLINFO_RESPONSE_CODE.html etc. John --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libcurl smtp error list?
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
Re: libcurl smtp error list?
On Friday 29 June 2018 01:02 PM, Daniel Stenberg wrote: On Fri, 29 Jun 2018, Deven wrote: I want to handle errors from curl_easy_perform() and provide a feedback to the users on what went wrong (SMTP server not correct, authentication failure, network not reachable, etc.). The errors mentioned in curl.h header are quite general (at least to me). Is there a list of protocol specific errors (in this case SMTP)? No, there isn't. And I'm afraid it isn't likely to ever exist one either. And it is actually a little done like this on purpose. 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. And if the return codes change across releases, then handling errors (to provide error feedback to the user) across different libcurl versions becomes impossible. Thanks, -Deven --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libcurl smtp error list?
On Fri, 29 Jun 2018, Deven wrote: I want to handle errors from curl_easy_perform() and provide a feedback to the users on what went wrong (SMTP server not correct, authentication failure, network not reachable, etc.). The errors mentioned in curl.h header are quite general (at least to me). Is there a list of protocol specific errors (in this case SMTP)? No, there isn't. And I'm afraid it isn't likely to ever exist one either. And it is actually a little done like this on purpose. 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. -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
