Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: giving users options when responding to backend specific errors #937

Open
dvdsk opened this issue Jan 11, 2025 · 0 comments
Open

Comments

@dvdsk
Copy link
Contributor

dvdsk commented Jan 11, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant