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

Managing errors #14

Open
julienw opened this issue Apr 15, 2016 · 4 comments
Open

Managing errors #14

julienw opened this issue Apr 15, 2016 · 4 comments

Comments

@julienw
Copy link

julienw commented Apr 15, 2016

For reference, here is the current code: https://github.com/fxbox/foxbox/blob/998b6e0e1e1fd3cba3b711783eaa7000c2f66a0d/src/adapters/mod.rs#L61-L69

Basically we unwrap on any error. Some adapters are not returning an Error for some errors because of this.

The end-user can't see panics because his only access is through a web browser. So we need another way to log the error instead and let the user act on it (especially we might need to be able to restart the foxbox from the browser -- but this is for another issue, I think).

First tentative solution:

  • init methods return a taxonomied error enum.
  • this error would show error levels: eg: Warn, Fatal, Critical.
  • this error would contain the cause. The cause should be a real error that implements Display/Debug/Error.
  • the box would log the result somewhere the user can look at (but this can be in a separate RFC). For now we could simply log warnings and panic at fatal and critical errors.

Second tentative solution:

  • we replace env_logger with a logger that would keep the logs in a central place to display it through a we bbrowser
  • the adapters init function directly uses this to log what needs to be logged
  • the adapters init function returns a Error only for Critical errors.
@Yoric
Copy link

Yoric commented Apr 15, 2016

I fully agree that the problem exists.

Any chance you could turn this RFC into one (or more) Pull Requests (with examples) so that we can comment line-by-line?

@julienw
Copy link
Author

julienw commented Apr 15, 2016

Yes, but I just couldn't yet. I merely braindumped.

@julienw
Copy link
Author

julienw commented Apr 20, 2016

After discussing with @JohanLorenzo I think we can rename this to "Manage errors" because this is broader than just the adapters start.

@julienw julienw changed the title Managing errors when adapters start Managing errors Apr 20, 2016
julienw added a commit to julienw/RFC that referenced this issue Apr 20, 2016
@julienw
Copy link
Author

julienw commented Apr 20, 2016

Created PR #16

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

2 participants