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
Global error management #2824
base: next
Are you sure you want to change the base?
Global error management #2824
Conversation
- A single place where error management / logging takes place - overridable functions so that clients can customize behavior
++ for some kind of encapsulation of the I like the onerror suggestion, however this will clash with native onerror-able elements like Maybe it's an idea to take some queues from how React handled nested component errors (error boundaries) and document a pattern that creates a "virtual" mithril element and wraps an existing component tree |
+1 for the log/error management being separate concerns. That said, clients can register two events: "log" and "fail". Come to think of it, "fail" is a pretty bad name. Maybe "error" would be better. Would you prefer having two different objects entirely dedicated? One for logging and one for error management? As far as stack traces are concerned, if you
I'll have a look at your React link, thanks |
@pieroxy I have some questions around behavior:
|
Hello!
In this new light, my answers:
Keep in mind this is a proposal open for discussion :-) I've been using mithril for all my web apps for the last 6 years, and I've been bitten a few times by my own bugs being silently blowing up on phones and browsers of my users, hence my will to handle errors correctly. But I'm still discovering the internals of mithril so I'm tiptoeing around for now. Thanks for your interest |
Description
I introduced an object called errorManager in mithril. Its goal is to be a centralized place to handle errors and logging.
Motivation and Context
Note: This is not supposed to be merged "as-is", but I am looking for feedback as to whether this type of change could be merged if I push it all the way (and also whether I did it the "right" way or not).
This change is here to help people that write apps with mithril handle errors (such as exceptions) in their code. This has two main goals:
console.log
cannot handle that. You need to call back somewhere to log all (or a sample of) errors happening. With this change the user can plug its own callbacks.Remains to be done (in my view):
view
(oninit
,oncreate
, ...)onerror
. Default behavior should use this method if it exists.How Has This Been Tested?
https://pieroxy.net/test-mithril/
Types of changes
Checklist:
docs/changelog.md