-
Notifications
You must be signed in to change notification settings - Fork 15
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
Analysis-time errors should be halting #31
Comments
Here's an interesting thought related to analysis-time work. There does exist one-and-only-one hook in the HTMLElement class that you can depend on to be called before any 🥁 - rull
I think this is actually pretty neat and leads me maybe change my mind about dispatching an error... I.e., I think maybe we should throw a halting error instead. The
I'm going to update the description to reflect this change in opinion, I believe a history of edits is kept now, so feel free to peruse that if you need the context. |
@klebba , you won me over on this one. Thanks for entertaining my bad idea 👍 |
Hah, it was not a bad idea! Glad you were able to work through both options |
Eventually, we want analysis to be one-time, static work that is cached per class. Therefore, we should not rely on having a target on which to dispatch errors. Closes #31
Eventually, we want analysis to be one-time, static work that is cached per class. Therefore, we should not rely on having a target on which to dispatch errors. Closes #31
Eventually, we want analysis to be one-time, static work that is cached per class. Therefore, we should not rely on having a target on which to dispatch errors. Closes #31
Currently, analysis work actually uses an instance (to resolve methods, etc). This allows us to dispatch errors at runtime instead of just throwing errors. Because we're not throwing halting errors, we're able to consider these errors non-fatal and move on.
In light of the comment below about the truly static
observeAttributes
hook and in light of discussions about making both computed methods and observers static #30, I propose we do cause a halting error.It will:
As long as analysis is truly static, you know that if an instance boots in development, it will boot in production, so it's not really possible to cause an error in production if you got the thing working in development.
The text was updated successfully, but these errors were encountered: