1、关于java方法设计

一、抛出问题

在java中，我们的方法该怎么设计，才能满足如下条件？

a、方法健壮

b、代码易于他人阅读

c、异常易于定位

二、进入讨论

a、为何方法要很健壮？

回答这个问题，可以联系我们日常生活去理解“健壮”这个词。顾名思义：健康又强壮，可称之为健壮。健壮有什么好处呢？好处如下：不用经历病痛、可以欢快的奔跑在鲜花盛开的乡间小路上。可以一边喝着冰雪碧一边吃烤生蚝，这种生活安逸不？如果不健壮，就很可能动不动的感冒、发烧，各种打针吃药，一天天的没精神，需要别人照顾，这种生活怕是有点糟糕。相应的，如果我们写的Controller方法，动不动就调用报错。前端动不动就能得500。用户使用系统时，动不动的就是：“我点这里怎么又没有反应了？”，那将是怎样一种体验？是不是心中奔腾而过一万只草泥马。所以，我们的方法一定要合理设计，使其健壮。不管什么时候，对于前端来说，返回给他们的：1、绝对不能是一串长长的java异常信息 ，2、绝对不能是500。即便是我们的代码真的出现异常报错了，返回前端的也一定得是200的状态码，再委婉告诉他：系统异常，请联系管理员！对于调用者来说，除非数据有问题，否则不应该出现异常报错。而且，假如报错了，一定要把异常信息throw给调用者。让他知道，调用报错的原因，方便他修正问题。spring源码中的方法，就是这么设计的。使用spring框架如果报错了，得到的错误信息一定是具体的信息吧，例如说找不到xml文件呀、xml内容不规范、找不到符合的bean进行注入等具体提示信息。而不是什么空指针、数组越界、运行时异常等等这些jdk异常吧。有了具体异常信息，自然就能知道问题在哪，该怎么解决。

b、代码易于他人阅读

一个系统的代码，绝对不是靠一人之力完成coding的。从编码-->到上线-->到上线后的维护扩展。这个过程中，伴随着开发人员的流动。系统的代码会经历过许多人维护修改。而每个人coding的水平、理念、风格各不相同。有的人写代码，从不注意代码的排版，一个方法八九个参数，一个if判断一个横屏都装不下。有的人写代码，一个方法超级无敌长。读他的方法，读到后边已经不知道前边都干了些什么。有的人写代码从不使用throw关键字，什么情况都是return，catch里永远都是Exception。所以到项目上线以后的维护阶段，极为难受。风格不一的代码、重复的判断、无用的变量、难以理解的逻辑、任谁来接手，都是头大。种种的这些，告诉我们一个深刻的道理。一定要将代码写得规范整洁，一定要有工匠精神，将代码写得像字一样漂亮，像诗一样优雅。不要让后来接手你代码的人上来就是：这垃圾代码，是谁写的？而一个公司，更是需要这样的代码，否则项目将面临失控最后over。

c、异常易于定位

代码，在编码阶段，通过开发工具的debug功能。我们很容易发现bug，然后可以迅速对bug做出修改。可是一旦项目部署上线，生产环境出现了bug，那么我们该怎么办呢？生产环境可没有debug这种操作。这种情况下，我们只有借助日志来迅速定位问题了。所以我们在coding阶段，一定要打好日志。try-catch/throw/throws等关键字，一定要用好了。一个系统，如果日志打得好，那么维护阶段必定是极为舒服的，反之将痛苦不堪、不胜折磨。