Error Message

[nadar]

The library provides to many error message properties. They need either a better documentation or we should provide the user an error message function which returns the right message. The following error message properties are available:

• curl_error_message
• http_error_message
• error_message
• getErrorMessage()

I assume that error_message contains the what users are looking for, either its a curl error or a http request error but there is also getErrorMessage() which is equals to curl_error_message.

What could we do to improve the developer experience?

[amouhzi]

I think what needs to be done is just improve the documentation, because I think we should keep this library lightweight for applications that use it. Improving the developer experience requires a lot of refactoring and implementation of some PSRs, which involves breaking changes and doing a major release, which takes time and effort. Right now, I'm running out of time to do this work. But I'm not against Pull Requests for that.

[nadar]

Improving the docs sounds good to me. I totally agree with lightweight experience of the library, also therefore i don't think its NOT necessary to implement PSR's, as there are ton's of other libraries which does this already.

so in order to always get an error message, people must use the $error_message property, right? Maybe you could explain the differences i asked, i will do a PR afterwards. Maybe introducing a new method, and deprecating getErrorMessage().

[nadar]

@amouhzi i stumbled on this again by myself in a project. There are so many error retrieving options that i am still not sure, what to use to get the latest proper error message.

Maybe we could introduce in 3.0:

• getErrorMessage(): rename to getCurlClientErrorMessage()
• getErrorMessage(): Using the value of $error_message

This should not be a big problem, since developers get better error messages after that change.