我是如何写Service的

对于一个不是很大的系统， 异常信息用“魔术数字般”的错误代码就是自找麻烦， 楼主用枚举的好处是既有代码提示， 又有编译检查。 后续结合Property文件， 做异常提示的国际化应该很省功夫。

像“您添加的用户名已经存在”这样的业务异常，是以状态码的形式返回好呢，还是以抛异常的形式返回好呢。

貌似这个问题曾经也是一个争得你死我活的问题，有人认为抛异常的方式浪费系统资源，影响性能，有人认为异常是符合对象编程的行为方式，而不应该再回到过去那种返回状态码的原始c编程形式。两种方式当然各有利弊，LZ你能凭你4年的经验告诉我一个准备有效的方案吗

我们现在是层内部函数调用都是采用返回一个非0的code.
但是层与层之间采用抛出业务异常exception,然后带不同的code.上层在捕获异常后先检查"特别"code(具体哪些code需要特别处理,可配置),否则就按统一的异常处理.
但是这样也有个很严重的问题,就是有时候仅仅一个code不足与提供整个错误的环境,所以在exception中不但要带一个code,还有一个Object的参数.当有需要的时候,由下层提供必要环境对象,上层再根据约定将该对象转型后使用.这种情况虽然很少,但是很恶心.
求达人讲讲这方面比较好的实践.

很赞。不过，一般来说，SERVICE可预测性太少。除了细节问题，更多的是由于业务问题导致的编程困难。

感谢楼主让我学到了不少东西，尤其SERVICE层异常处理的方式，以前从来没想过用ENUM来标示。BTW，我还没毕业，做的系统还比较少好。希望这里的高手们多写点技术经验，感谢极了。。

服务层异常全抛运行时异常，你这个也忒诡异了吧

楼主要上岸了

挺好的  断言没怎么用过...断言 和 if  那个效率好啊

期待楼主的精彩后续！

假如不用性能工具，我们一般会用80%的时间来调整20%的性能，意思说有些性能问题是写代码的时候可以暂时忽略。
另外我认为应该使用状态码，举一个例子，工单系统需要对外提供“派发工单”的接口，这种接口一般是提供给外部系统使用的，如何处理，应该由调用方自己决定，本系统只要在接口文档里详细描述每一个状态码所代表的意义即可。
另外也衍生一个话题，即数据和展现的分层，我们写代码的时候应该将数据和展现分离，如Action只提供数据（如JSON数据），至于客户端(C,HTML，JAVA,.net)如何展现他们自己决定。