如何更好地用Java中的异常抛出

  之前，我以为编程语言中最让人不解的部分就是它可以建立错误。当时我对Java语言中的throw关键字的第一反应就是“啊，这也太傻了，为何咱们想要 引起一个错误(error)？”我以为错误是个人敌人，应当避免的，因此建立错误是毫无用处甚至是危险的。我认为在JavaScript中加入这样的关键 字是画蛇添足。但随着我编程经验的丰富，我逐渐变成了throw个人error粉丝。合理的使用它们会让对代码的调试和维护大大简化。

        在编程的时候，Error一般出如今不指望的事情发生时。多是传入函数的参数值不正确，或者是运算符的操做数不合法。为此编程语言定义了一个基本的规 则：当上述状况发生时，就产生一个错误来让编程人员对代码进行修复。若是这些错误不被抛出或反馈给你，那么调试程序几乎是不可能的。若是全部的错误都“悄 悄地”发生，那么你很难在第一时间发现问题所在，并将其修复。所以Error是开发者的朋友，而不是敌人。

        Error的问题所在是它们会在错误的时间和错误的地点发生。更糟的是，默认的错误信息一般晦涩难懂，很难解释哪里出了问题。JavaScirpt的错误 信息更是不包含任何有价值的信息，并且还很隐蔽(尤为是在IE里运行时)。想象一下若是能有这样的错误提示出现“由于某件事情发生致使某个函数调用失败 ”，那么马上咱们的调试任务就变得简单了，这就是throw本身的error的好处。

        咱们能够把error想象成内嵌的异常类。在代码的某个特定的地点估计异常的发生确定要比在全部的地方等待异常的发生要简单。这不光在代码编写中，在产品 设计中也是一个广泛认同的原则。就像在轿车上设计了挤压区域和框架，以便在受到撞击时会以指望的方式发生变形。由于知道了框架在受到撞击时会如何变形，哪 些零件会失效，这样制造商就能够造出保证乘客安全的汽车。咱们的代码也能够按照这样的思想编写。

        虽然最近几年JavaScript有了不少进步，可是相比于其它语言的开发者，JavaScript开发者仍然只有少得可怜的调试工具。所以在 JavaScript中throw error就显得比其它语言更有价值。咱们能够用throw关键字来抛出一个对象。咱们能够抛出任何类型的对象，不过Error对象是最经常使用的：

throw new Error("Something bad happened.")

        当咱们用这样的方式抛出错误，而这个错误又不被try-catch捕获时，浏览器就会用其一般的方式显示上面的错误信息(Something bad happened)。在IE里会在浏览器的左下角出现一个小图标，当双击图标时会弹出一个带着上面错误提示的对话框；安装有Firebug插件的火狐浏览 器会在控制台显示错误信息；Safar和Chrome会在Web Inspector中显示；Opera会在错误控制台显示。一句话，它们会像你没有抛出错误时同样处理。但不一样的是它会经过浏览器向你提供具体的信息，而 不是一个发生错误的行列号。你能够为错误信息加入任何须要的信息，来帮你成功解决问题。我建议在错误信息中提供发生错误的函数名称以及错误缘由。看下面这 个函数：

function addClass(element, className){
        element.className += " " + className;
}

        这个函数的功能是向一个给定的element加入新的CSS class(这在JavaScript中很是广泛)。但若是element是null的时候会发生什么？你会获得一个这样的错误提示“object expected”，很隐晦。而后你须要查看执行堆栈(若是浏览器支持这个功能)来准肯定位错误的源头。若是咱们抛出一个错误调试就变得简单了：

function addClass(element, className){
       if (element != null && typeof element.className == "string"){
        element.className += " " + className;
        } else {
        throw new Error("addClass(): First arg must be a DOM element.");
        }
}

先不讨论如何精确的判断对象是不是一个DOM element，这个方法如今可以在非法的element参数传入时提供一个更明确的错误信息。看到了如此详尽的错误描述你就能马上找到错误的源头了。我 习惯把throw error看做是贴一个任务贴纸，告诉我错误的缘由。

        懂得了如何throw error只是事情的一半；懂得什么时候throw error则是另外一半。由于JavaScript并不对参数进行类型检查，许多开发者都错误的认为他们应该在全部的函数中进行该检查。那样的话是不实际 的，并且会下降脚本的执行效率。问题的关键在于找到最有可能出错的代码部分，而且只在那里throw error。一句话就是只在已经发生error的地方throw error。

        若是一个函数只被一个已知的实体调用，那么错误检查基本上是没有必要的(例如私有函数就是这样)；若是你不能事先肯定全部函数被调用的地点，那么你须要进 行错误检查并throw本身的error。throw error最好的地方是功能函数，那些是脚本环境基本组成部分的，并且能够在任意地点被调用的函数。JavaScript的库函数就是这样的例子。

        全部JavaScript的库函数都应当为已知的错误条件从它们的公共接口throw error。对于YUI，jQuery以及Dojo等等，咱们没法肯定会在什么时候何处调用它们的库函数。因此当你犯错时对你进行提示就是这些库函数的任务。 为何呢？由于你不可能到库函数内部去找出错误所在。error的调用堆栈应当终止于库函数接口，不要再深刻。没有什么比在12层函数嵌套中寻找错误更遭 的事了；库函数开发人员有责任预防这种事情的发生。

        这一条一样适用于私有的JavaScript库函数。许多Web应用程序都有它们本身专属的JavaScript库，多是经过这些库来构建的，也多是 用库来代替公共的操做。库函数的做用是下降开发难度，这是经过向人们提供其抽象表达而不是复杂的实现细节来实现的。throw error可让这些复杂的实现隐藏在安全的地方不被开发者发现。

        JavaScript一样提供了try-catch语句，用来在浏览器处理以前捕获被throw的error。开发者经常会为究竟是仅仅throw error仍是用try-catch将其捕获而犹豫不决。咱们应当只在程序栈的最底层throw error，就像前面提到的，最典型的就是JavaScript库函数。全部应用程序都应当在逻辑上具备处理error的能力，所以应当在底层模块中捕获 error。

        在应用程序逻辑中咱们老是知道为何要调用某个函数，所以它们很是适合处理error。有一点要引发注意，就是永远不要在try-catch结构中使用空 的catch语句；你应当用某种方法处理错误。这钟处理在开发中和最终生产时会有些不一样，但必须进行处理。当错误发生时，不该当仅仅将其包裹在try- catch里无论——这是掩盖错误而不是解决错误。

        在JavaScript中throw error是一门艺术。在代码中找到适当的throw error的地点会花费一些时间。不过一旦你找到了这些地点，你的调试时间就会大大下降，而你对代码的满意度会得到提高。