Error handling
swagggpickle opened this issue · 3 comments
Hello,
I just started to use this package and I stumbled across some interesting behavior, I noticed that whenever a syscall.EAGAIN
is received no error is returned and potentially a nil value is also returned. Example 1 Example 2
Typically in Go you would propagate an error like this to allow the application layer to be able to change behavior.
Is there a particular reason for not propagating the error?
Here is a comment from decode.h
of libavcodec
/**
* Called by decoders to get the next packet for decoding.
*
* @param pkt An empty packet to be filled with data.
* @return 0 if a new reference has been successfully written to pkt
* AVERROR(EAGAIN) if no data is currently available
* AVERROR_EOF if and end of stream has been reached, so no more data
* will be available
*/
This is why.
Yes I understand the comment. The issue I am having is these two errors are being masked/not returned or propagated. If the error EAGAIN, error i am receiving, is received my application code should retry again but since I never received the error I have no way of making a smart application level decision. I would happily make a PR to allow for these values to be propagated if you agree they should be.
Feel free to contribute, would be great to have another one Decode function, let's name it Decode2 for backward compatibility