2 ms·
Speaking for us (Sentry) it's utterly frustrating that we now have to add framework specific code in so that error handling works again for customers. I think
by the_mitsuhiko 10y ago
Speaking for us (Sentry) it's utterly frustrating that we now have to add framework specific code in so that error handling works again for customers. I think the number one complaint was minified exceptions over the last year where we just encouraged people to not run with the production environment. This is clearly a step to something where customers can be satisfied but the cost is that we now scrape your codes.json and add custom handling just for React.
It's a terrible precedent and lacks any sort of standard :-/ I'm not a fan of this sort of pattern spreading.
- sebmarkbage 10y agoIf it spread to a become a defacto standard format, wouldn't that be a good thing? That way you only have to deal with this once and it will work everywhere. At that time, the size/parse time will have much greater impact because the total size of libraries will be smaller or unaffected. At the same time it encourages libraries to put significant error messages in their code without fear of bloat which helps your customers in the end. Personally, I hope everyone will follow.
- the_mitsuhiko 10y agoSince the URL to the raw mapping is not in the error and requires external knowledge and the parameters are in free form in the error message I doubt this can become a standard of any sorts. The correct place for this would have been something like sourcemaps.
- sebmarkbage 10y agoYea, this is clearly not enough to be a standard but we don't really know of a standard for this and it is not really our primary expertise. If Sentry or others that understand this problem space better create a standard format, we would be happy to switch to that. Everything have to start somewhere. :)