On Mon, 7 Nov 2005, Leo Huf Campos Braga wrote:

> I'm writing a simple c++ class that performs some basic libcurl
> operations trough object oriented programming.

Did you see the curlpp binding? It does just that:
http://rrette.com/curlpp.html

> When creating a CurlException class, I came accross the following dillema:
> many of the returned error codes are not really serious errors, most of them
> are just caused by a url typo, or a internet server down, something like
> that.

Why is that a dilemma?

> preliminary list of errors that should really terminate the program
> execution:

...

Looked ok, except for CURLE_ABORTED_BY_CALLBACK which only gets called if your
callback has made it abort and then no one but you and your app can judge the
"serious" level of this error code.

> The only problem is that, well, I really don't know libcurl errors very
> much, even because I just started working with it.

They're documented, and there's source to check details in.

> For an example, I have no idea what LDAP is, and more or less selected all
> LDAP errors as exception generators. I have others doubts relating to, for
> an example, CURLE_SEND_ERROR (55) and CURLE_RECV_ERROR (56), because if this
> errors means that libcurl is not succeding in connecting to the internet,
> maybe it should really exit the program execution, as all other tries to
> connect to any other internet addresses will also fail.

Yes, perhaps. But the point of having them as special and separated error
codes is that the decision on how to act when they are returned can be judged
by the app and depend on the situation, platform etc.

I see what you do, I don't quite understand the reason.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html