在Java开发过程中,见过很多人在进行异常处理的时候,直接一个 e.printStackTrace() 就完成了,这是一种非常粗陋的做法,首先会导致应用日志的大量错误信息,而很多时候你都不知道这些错误信息因何发生;再者,反应到用户端将直接导致用户无法获取操作的结果以及失败的原因。
以下 15 条异常处理的原则来自国外的博客:
不用使用异常来管理业务逻辑,应该使用条件语句。如果一个控制逻辑可通过 if-else 语句来简单完成的,那就不用使用异常,因为异常会降低代码的可读性和性能,例如一些 null 的判断逻辑、除0的控制等等;
异常的名字必须清晰而且有具体的意思,表示异常发生的问题,例如 FileNotFoundException 就很清晰直观
当方法判断出错该返回时应该抛出异常,而不是返回一些错误值,因为错误值难以理解而且不够直观,例如抛出 FileNotFoundException 异常,而不是返回 -1 或者 -2 之类的错误值。
应该捕获指定的异常,而不是 catch(Exception e) 了事,这对性能、代码的可读性以及诸多方面都有好处
Null 的判断逻辑并不是一成不变的,当方法允许返回 null 的时候使用 if-else 控制逻辑,否则就抛出 N
以下 15 条异常处理的原则来自国外的博客:
不用使用异常来管理业务逻辑,应该使用条件语句。如果一个控制逻辑可通过 if-else 语句来简单完成的,那就不用使用异常,因为异常会降低代码的可读性和性能,例如一些 null 的判断逻辑、除0的控制等等;
异常的名字必须清晰而且有具体的意思,表示异常发生的问题,例如 FileNotFoundException 就很清晰直观
当方法判断出错该返回时应该抛出异常,而不是返回一些错误值,因为错误值难以理解而且不够直观,例如抛出 FileNotFoundException 异常,而不是返回 -1 或者 -2 之类的错误值。
应该捕获指定的异常,而不是 catch(Exception e) 了事,这对性能、代码的可读性以及诸多方面都有好处
Null 的判断逻辑并不是一成不变的,当方法允许返回 null 的时候使用 if-else 控制逻辑,否则就抛出 N