qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: question about proton error philosophy
Date Mon, 16 Sep 2013 17:23:26 GMT
FYI, as of 0.5 you should be able to use pn_messenger_error(pn_messenger_t
*) to access the underlying error object (pn_error_t *) and clear it if an
error has occurred.

--Rafael

On Mon, Sep 16, 2013 at 12:40 PM, Michael Goulish <mgoulish@redhat.com>wrote:

>
> No, you're right.
>
>     "errno is never set to zero by any system call or library function"
>     ( That's from Linux doco. )
>
> OK, I was just philosophically challenged.
> I think what confused me was the line in the current Proton C doc (about
> errno) that says "an error code or zero if there is no error."
> I'll just remove that line.
>
> OK, I withdraw the question.
>
>
> ( I still don't like this philosophy, but the whole world is using it, and
> the whole world is bigger than I am... )
>
>
>
>
> ----- Original Message -----
> Do other APIs reset the errno?  I could have sworn they didn't.
>
> On Mon, Sep 16, 2013 at 12:01 PM, Michael Goulish <mgoulish@redhat.com>
> wrote:
> >
> > I was expecting errno inside the messenger to be reset to 0 at the end
> of any successful API call.
> >
> > It isn't: instead it looks like the idea is that errno preserves the
> most recent error that happened, regardless of how long ago that might be.
> >
> > Is this intentional?
> >
> > I am having a hard time understanding why we would not want errno to
> always represent the messenger state as of the completion of the most
> recent API call.
> >
> >
> > I would be happy to submit a patch to make it work this way, and see
> what people think ----- but not if I am merely exhibiting my own
> philosophical ignorance here.
> >
> >
>
>
>
> --
> Hiram Chirino
>
> Engineering | Red Hat, Inc.
>
> hchirino@redhat.com | fusesource.com | redhat.com
>
> skype: hiramchirino | twitter: @hiramchirino
>
> blog: Hiram Chirino's Bit Mojo
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message