proposal: giving users options when responding to backend specific errors

[yara-blue]

Right now when receiving an BackendSpecificError you can either:

• close the stream on the first BackendSpecificError since you have no idea if its critical, but that means an underrun is not recoverable. You could try accepting a few errors and only then aborting but this is still very brittle.
• continue in the hope that error will clear, probably correct behavior for underruns.

Possible backward compatible solution:

impl BackendSpecificError {
  fn is_recoverable(&self) -> Option<bool>;
}

This would return None if it is not known whether the error is recoverable or not. The error struct would stay the same, simply a description as String. The function would work by searching for known error messages, such as ALSA underruns in the description.

Alternative

Parse all errors as they occur, do away with BackendSpecificError making a separate enum for each backend. Disadvantage lots of work, parsing always happens instead of being a choice for the user. Advantage no more need to allocate a String for every error. We would probably still need the String fallback in case we can not parse/recognize the error. What this means for performance, no idea.

[roderickvd]

In a8b016c I added two variants to the StreamError enum, one of them BufferUnderrun precisely to indicate that you can continue the stream. If (for ALSA) the underrun was not recoverable, then it still signals a BackendSpecificError. Hope this meets this use case. If not, feel free to reopen!