对异常的捕获和处理是提高程序鲁棒性的一个重要方式，即使在javascript/nodejs等看似“很难写出bug”的弱类型语言里，异常捕获处理仍至关重要，这主要是因为：
1.在一个代码块里，如果程序运行过程中自动、或主动（new Error/Exception）生成异常/错误后，若不主动去try...catch该异常，这个异常会逐层抛出，直至主程序，系统会按照框架默认方式处理该异常。
2.在逐层抛出异常的过程中，每层代码块异常点之后的程序不会再被执行，除非进行try...catch异常处理。
我们看几个简单的例子来验证一下。
(() => {
try{
(()=>{
nonExistentFunction();
console.log('c');
})();
console.log( 'b' );
}catch(e){
console.log( e );
}
})();
console.log( 'a' );
打印结果：
即，打印了最外层的catch内的异常处理信息和主程序接下来的部分，根据1,2可知，如果匿名函数最外层没有进行try...catch处理的话，a也不会被打印出来。
这意味着，即使是“很难写出bug”的javascript也可能因为一个小小的异常导致整个程序歇菜！try...catch则是保证主干按流程执行完毕的关键实现。
容易被误处理的异步异常
在nodejs等异步IO密集场景，经常用异步回调函数来处理IO操作结果——不管是正确的数据还是异常Error,但此时的try...catch怎么来写？
const fs = require('fs');
try{
fs.readFile( __dirname+'/15_fs1.js',(err,data) =>{
if( err ){
throw err;
}else{
console.log( data );
}
} );
}catch(err){
console.log( 'an error occured!',err );
}
console.log( 'hhh' );在文件不存在的情况下，按照try..catch的作用，我们认为应该在catch里捕捉到异常并执行异常处理语句，即打印“an error occured!XXX”；但实际结果呢？
即，异常最后并未被目前缩写的catch所捕获，而是最终被系统级捕获并按照框架方式打印出了错误信息，这是为什么呢？主要是因为try...catch是代码块，是被同步解析的，当代码执行到try后，开始读文件操作，等待异步执行结果，但catch语句是紧接着try进行的，它并不会等待异步执行的结果，因此，当执行到catch的时候，回调里的throw error还没执行呢，当然catch不到了，主程序继续解析执行直到打印出'hhh'。随后当异步会调离throw err的时候没有catch可以捕获的到，只能层层抛出到最外层，由框架来捕获和执行。
理解上述内容后，就该想到问题的关键点是try...catch的执行ticker与回调函数ticker不同步的问题，解决的办法也很简单，同步try...catch与callback函数的时钟—将try..catch放在callback里面。
正确的代码示例：
const fs = require('fs');
fs.readFile( __dirname+'/15_fs1.js',(err,data) =>{
try{
if( err ){
throw err;
}else{
console.log( data );
}
}catch(e){
console.log( e );
}
} );
console.log( 'hhh' );打印结果：
19年要在使用新框架写好业务逻辑的基础上，提高自己输出代码的鲁棒性，经常去分析、反思可能出现异常的模块并进行forecast error的捕获处理，进一步提高自己的代码水平。
——学无止境，保持好奇。May stars guide your way.