4 ms·
> since I don't throw errors very often I call shenanigans. Maybe you don't intentionally throw exceptions very often, but that's hardly the point of exception
by ef4 14y ago
> since I don't throw errors very often
I call shenanigans. Maybe you don't intentionally throw exceptions very often, but that's hardly the point of exceptions.
Javascript is an interpreted language. Everything is an exception. Do you ever fat-finger a function name during development? That's an exception. Ever accidentally try to use "this" when it's pointing at "window"? Exception.
Those simple, natural mistakes can be lurking anywhere. They're far easier to detect and correct when the failure is propagated backward correctly to the right callers.
- k3n 14y agoAlso, the DOM. It's a sort of blackbox that has a mind [implementation] of its own, and if you don't treat it as such and/or if your code isn't bullet-proof (and honestly, most code isn't) then you'll get exceptions from even routine and mundane operations.
- joezimjs 14y agoYou guys are talking about things that should be discovered during development, in which case, I'd rather have the exception thrown and showing in the console than to try to write a function to handle them.
- ef4 14y agoEven in that case, it's easier to understand the exception if you have a meaningful stack trace. A good promise implementation gives you that. Also, I guarantee you will always get exceptions in production that you didn't see in development. Browsers are different, users do things you didn't think to test. If you care about quality, you need a system in place for reporting those exceptions back to the mothership, again including meaningful traces.