Get rid of huge error messages #14744
Comments
|
I guess we could make the max error message characters configurable on |
|
Yeah, I'd be happy to, but I'm not that familiar with angulars inner workings. Looking at My initial intention was to look at |
|
You are right. What do others think ? |
|
On a side node you can also use script blackboxing in devtools https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Black_box_a_source |
|
@Delapouite That has no effect on the issue though, unless I'm misunderstanding what you're suggesting. |
|
So, has anything new come up that would allow for this to be approached in a new way? Maybe some sane default could be implemented that recognizes that a URL like this is not going to help anyone:
|
|
Given that the nginx at errors.angularjs.org will return a 414 for a URI of that size and the default max length appears to be 8K, I would propose to make that the absolute limit for the generated URLs. However, an even saner approach would be preferable. |
|
Once #15433 is merged, it will open the way for adding more configuration options for error handling (i.e. |
|
Excellent, I will watch that ticket and get involved as needed. Thanks for the heads-up. |
…essagex configurable Closes angular#14744
…essages configurable Closes angular#14744
…essages configurable Closes angular#14744 Closes angular#15707
…essages configurable Closes angular#14744 Closes angular#15707
…essages configurable Closes angular#14744 Closes angular#15707
…essages configurable Closes angular#14744 Closes angular#15707
…essages configurable Closes angular#14744 Closes angular#15707
…essages configurable Closes angular#14744 Closes angular#15707
…essages configurable Closes angular#14744 Closes angular#15707
…essages configurable Closes angular#14744 Closes angular#15707
…essages configurable Closes angular#14744 Closes angular#15707
…essages configurable Closes angular#14744 Closes angular#15707
|
PS I just want to say I admire your efforts here on the Angular issue tracker @gkalpak, it seems every issue I raise, follow or comment on, you're involved somehow 😄 Great work staying on top of things, analysing issues, and providing useful insights/alternative solutions/feedback 💯 |
|
I just realised that this is not the function responsible for adding the URL :-) |
Notice that in minified builds we provide, the error messages are removed in order to further reduce the size. Only the error codes are retained (e.g.
That sounds like a better option. That's what I meant in #14744 (comment).
It is much simpler indeed. But we've never favored simplicity over dev experience just for the sake of simplicity 😛
We need to verify that this plays well with ng-closure-runner. (And it might require more boilerplate and internal knowledge from the user than necessary. But maybe still worth exploring for the flexibility it offers.) |
I use the non-minified code base in development and for production I minify the codebase myself.
Ok great, let's do that then 👍 |
error is truncated
In Angular.js the error in loading a module will lead to a failur in loading
the dependent modules. In turn, this leads to a chain of errors in loading
those modules. For some reason, angularjs is copying the error stack and
passes it to the next error. This stack is encoded in URL error,so we end up
sometimes with so long Error URL when we have may dependent modules.
This option disables encoding the parameters in URL error:
angular.errorHandlingConfig({isUrlParameter:false});
closes angular#14744
When some error occurs while loading a module, an error will raise containing the original error stack. Sometimes the final error contains a lot of stacks which make it difficult to read. closes angular#14744
|
I'm in a situation again where Angular will log such huge amounts of text that it instantly crashes DevTools. Can someone let me know where we are with this issue? We had @aalmkhieber working on this, but nothing ever came out of it. I would really like to get this resolved proper ASAP. |
|
Chrome to the rescue:
|
…L error is truncated
In Angular.js the error in loading a module will lead to a failur in loading
the dependent modules. In turn, this leads to a chain of errors in loading
those modules. For some reason, angularjs is copying the error stack and
passes it to the next error. This stack is encoded in URL error,so we end up
sometimes with so long Error URL when we have may dependent modules.
This option disables encoding the parameters in URL error:
angular.errorHandlingConfig({isUrlParameter:false});
closes angular#14744
Specific errors, such as nested module loading, can create very long error urls because they include the error stack. These urls create visual clutter in the browser console, are often not clickable, and may be rejected by the docs page because they are simply too long. We've already made improvements to the error display in angular#16283, which excludes the error url from error parameters, which results in cleaner error messages. Further, modern browsers restrict console message length intelligently. This option can still be useful for older browsers like Internet Explorer, or in general to reduce visual clutter in the console. Closes angular#14744
Specific errors, such as nested module loading, can create very long error urls because they include the error stack. These urls create visual clutter in the browser console, are often not clickable, and may be rejected by the docs page because they are simply too long. We've already made improvements to the error display in angular#16283, which excludes the error url from error parameters, which results in cleaner error messages. Further, modern browsers restrict console message length intelligently. This option can still be useful for older browsers like Internet Explorer, or in general to reduce visual clutter in the console. Closes angular#14744 Closes angular#15707 Closes angular#16283 Closes angular#16299
Specific errors, such as those during nested module loading, can create very long error urls because the error message includes the error stack. These urls create visual clutter in the browser console, are often not clickable, and may be rejected by the docs page because they are simply too long. We've already made improvements to the error display in #16283, which excludes the error url from error parameters, which results in cleaner error messages. Further, modern browsers restrict console message length intelligently. This option can still be useful for older browsers like Internet Explorer, or in general to reduce visual clutter in the console. Closes #14744 Closes #15707 Closes #16283 Closes #16299 Closes #16591
Specific errors, such as those during nested module loading, can create very long error urls because the error message includes the error stack. These urls create visual clutter in the browser console, are often not clickable, and may be rejected by the docs page because they are simply too long. We've already made improvements to the error display in #16283, which excludes the error url from error parameters, which results in cleaner error messages. Further, modern browsers restrict console message length intelligently. This option can still be useful for older browsers like Internet Explorer, or in general to reduce visual clutter in the console. Closes #14744 Closes #15707 Closes #16283 Closes #16299 Closes #16591
|
This is a little late to the party, but... For anyone like me who is maintaining legacy apps that use 1.5.11 or a similar version that suffers from this issue — It's probably easy to write this yourself, but here is a page that decodes the error URL for you. Feel free to bookmark: https://matts-apps.net/angularjs-error-decoder/ |
Do you want to request a feature or report a bug?
Feature.
What is the current behavior?
On certain errors, Angular will throw errors with insanely long error messages, which are not helpful and sometimes cause performance issues that bring the DevTools to a halt.
What is the expected behavior?
Error messages are either truncated or reduced to only include useful information. Optimally, the can be disabled completely.
What is the motivation / use case for changing the behavior?
These errors can be very frustrating to work with during development, as they fill up huge parts of the console and cause performance issues.
Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.
This has always been an issue and still is with 1.5.6. I'm working with Chrome stable on Windows 10.
Other information (e.g. stacktraces, related issues, suggestions how to fix)
Here is an example of what I'm referring to. Please note the length of some of these lines.
The text was updated successfully, but these errors were encountered: