and Hacker, passionate about web technologies. I develop with Node.js, Go, C/C++, React and Redux for the web. u I currently live in San Francisco and work as Software Engineer at GoDaddy. u Previously, I was Head of Engineering at Tribe App – An early backed Sequoia Capital startup based in Paris and San Francisco.
u Error objects are first class citizens u Runtime errors throw an Error object u It has a name, message and stack property u Besides the generic Error constructor, there are seven other core error constructors in JavaScript: EvalError, InternalError, RangeError, RefrenceError, SyntaxError, TypeError, URIError. var notRightError = new Error('This is not right!')
you throw something u In JS it’s good practice to throw Error objects u If an exception is unhandled, your process will exit throw new Error('this is the right way') throw 'avoid throwing non-Error stuff'
// do absolutely nothing } console.log(result) } try { // some code that can potentially throw } catch (err) { // this will never happen } Promise.catch((err) => { // ops, let's just ignore this ha ha }) socket.on('error', (err) => { // again, do nothing ! })
and handled in your application u Examples: Network timeouts, External service is not available or it returns errors, Unexpected or missing user inputs
await makeRequest('http://example.com/json') const parsedBody = JSON.parse(body) console.log(parsedBody) } catch (err) { // handle error } u Just syntax sugar for promises u It allows us to use Try/Catch
when you can u Programmer errors should NOT be handled u Have a global uncaughtException listener for errors you cannot not handle u Do not centralize handling of operational errors u When delivering errors, use the standard Error class and its standard properties