Comment #7 on issue 3019 by [email protected]: Need a better way to
stringify functions in error messages
http://code.google.com/p/v8/issues/detail?id=3019
Sorry if I misdirected your attention, but I'm not saying that we
implemented a limit of 100, and we should change V8 to work with that
limit. (In fact we haven't decided on what the limit should be yet, all I
know is that we have to put some limit there.)
I think I am really arguing for two things. First, the current message is
bad for usability and confusing for the average developer. Second, the
current message is bad for reporting tools.
I have attached a screenshot from chrome's console to give you a feel of
what it actually looks like. I am fully aware that V8 is being used in a
lot more places than just in chrome, and that your patch apply to more than
just functions (although I doubt anything else would be long enough to hit
the limit, except long strings maybe) but I think my arguments are pretty
generic in these regards and can be extrapolated to most scenarios.
My argument for lowering the limit and rewording the error mainly applies
to my my first point (usability):
A. the most helpful piece of information that helps identify the function
is the function signature, the body is mostly just noise when trying to
understand the error, except when the source is minified. In that case
neither the signature nor the body is really going to help, and the method
name is going to be most helpful.
B. In fact it's arguable that the method name is *most* important in all
cases, because I can easily search my source code for that token and see
where I tried to call that method, whereas I might not have written the
original function myself (e.g. Backbone.Model comes from a library) and so
searching for the function signature/body might not yield any results in my
local codebase.
C. The error message is very difficult to read/scan when the important
pieces of information are separated by/buried inside a large body of noise
(if you just scan it quickly, you might miss that there's relevant stuff at
the end)
D. Regardless of what we do, the error message *will* be truncated in a lot
of cases. Expanding the error in chrome dev tool is an example (shown in
the screenshot). Emails subjects and push notification is another.
Therefore it is desirable to keep the relevant information at the beginning
whenever possible.
Now, for my second point, it's a relatively minor concern for us compared
to the usability. We haven't settled on the limit yet, but the feedback I
can provide from our perspective is that, it's desirable for the limit to
be as low as possible. This is for a few reason:
A. This string is being transferred from the end-user's device back to our
server, and these devices might be on low bandwidth links (i.e. mobile
devices), so it's desirable to minimize the data being sent.
B. When a developer deploys a new version of a popular site/app, and an
error like this happens, the error collection could be hit by a lot of
devices at at the same time, and these bytes adds up quickly. (This is not
really a problem for us, because we also collect stack traces, which is
easily orders of magnitude larger, so are prepared to deal with that
anyway. But this applies to a lot of other collection services, especially
home-grown ones.)
C. We don't do it this way, but a lot of collection services actually uses
a GET request to send these pings (e.g. Google Analytics..!), and some
browser/servers have a pretty low limit on the maximum URL length.
This is definitely not a problem that is unique to us. For instance, Google
Analytics recently launched the Universal Analytics beta, which has support
for collection exceptions, and they have a limit of 150 characters on the
exception message (see
https://developers.google.com/analytics/devguides/collection/analyticsjs/field-reference#exDescription).
Keep in mind that's for the entire error message, not just the FormatString
partial result.
While we can quite easily detect this and reformat the message ourselves, I
strongly feel that these problems are not unique to us, and our intention
is to take this opportunity to make things better for everyone.
May I ask how you derived that the 256 characters limit? What are the use
cases you have in mind? Perhaps we can work out a lower limit (GA's 150
characters might be a good target to work towards) that still works well
for those use cases?
Attachments:
Screenshot_2013-11-29_11_28_AM-2.png 562 KB
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
