You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please discuss your new feature before implementing it if it's nontrivial. Adding a small method is probably trivial, anything larger than that, maybe not. Note that API stability is paramount.
Many of the encoding & decoding functions communicate the state of the decoder/encoders via the posix EAGAIN code (example: 1, 2). This code is even so important, that the documentation calls out how to find it, I can only assume as a way to help consumers of the library.
So why isn't EAGAIN part of the Error enum?
The advantage is obvious it would take
for(stream,packet)in input.packets(){if stream.index() == idx {match output_decoder.send_packet(&packet){Ok(()) => {},// Why does such a common case require so much visual noise?Err(Error::Other{code:EAGAIN}) => {// get data out of the decoder}Err(e) => returnErr(e),};}}
into
for(stream,packet)in input.packets(){if stream.index() == idx {match output_decoder.send_packet(&packet){Ok(()) => {},Err(Error::EAgain) => {// get data out of the decoder }Err(e) => returnErr(e),};}}
It feels like the most common case that needs special error handling shouldn't require the most visual space.
This more closely follows the "flow" of C code examples, e.g.:
rc=send_packet(decoder_ptr, packet_ptr);
ifrc==0 {
continue;
} elseifrc==EAGAIN {
/* get data out of the decoder */
} else {
returnrc;
}
The very obvious, "I need to read data out of decoder/encoder" return code shouldn't be buried.
The text was updated successfully, but these errors were encountered:
Please discuss your new feature before implementing it if it's nontrivial. Adding a small method is probably trivial, anything larger than that, maybe not. Note that API stability is paramount.
Many of the encoding & decoding functions communicate the state of the decoder/encoders via the posix
EAGAIN
code (example: 1, 2). This code is even so important, that the documentation calls out how to find it, I can only assume as a way to help consumers of the library.So why isn't
EAGAIN
part of theError
enum?The advantage is obvious it would take
into
It feels like the most common case that needs special error handling shouldn't require the most visual space.
This more closely follows the "flow" of C code examples, e.g.:
The very obvious, "I need to read data out of decoder/encoder" return code shouldn't be buried.
The text was updated successfully, but these errors were encountered: