36 | 实战二（上）：程序出错该返回啥？NULL、异常、错误码、空对象？

大家好,第一次发言。有个疑问:各位在Service层返回的是对象还是Result接口

第二种返回Null的情况，可以使用Optional吗

这句话不太理解，即便是可恢复的异常依然是向上抛更合理，比如提现金额大于余额就应该告知用户啊。实在想不明白受检查异常的用武之地在哪？ 对于代码 bug（比如数组越界）以及不可恢复异常（比如数据库连接失败），即便我们捕获了，也做不了太多事情，所以，我们倾向于使用非受检异常。对于可恢复异常、业务异常，比如提现金额大于余额的异常，我们更倾向于使用受检异常，明确告知调用者需要捕获处理。

Happy new year！ 鼠年大吉🎊🎈🎉🍾️🎆🧧

返回空对象章节中，return Collectiosn.emptyList();出现拼写错误，应该是Collections.emptyList();

回答问题 1.抛出异常，因为服务器获取不到host是一种异常情况，并且打印的异常日志不能是warm,而是err，因为该异常不会自动回复。 2.往上抛，原封不动。应该在api统一出口处处理异常，这样异常代码会比较聚合（个人习惯）。该异常描述已经很准确，且处理异常依旧在genId接口中，所以上层函数可以认识该异常，所以原封不动。（而统一出口函数，则可以抛自定义异常，以收敛api使用方的考虑范围）。 3.抛出异常，null值裁剪名称是一种异常情况。或则说，对于裁剪名称这个函数，入参不能为null。 4.返回空字符串。小于等于0说明不需要带随机后缀，这也是一个正常的业务场景。返回空字符串是为了方便调用方不用做null判断。 分歧： 1.get,find,select等dao层操作，返回null是正常业务情况，表示数据不存在。但在其应用层，数据不存在可能意味着有脏数据，数据缺失等情况，属于异常情况，需要抛出异常。所以同样是get方法，持久层返回null，业务层返回可能是异常。 2.异常流开销大，在对响应时间要求很严格的场景。放弃合理的异常处理，采用不合理的特殊返回值的方式也是合理的。所以合理的运用异常流在java也是一个选择项。在可读和性能我们需要权衡，而这两玩意经常是相驳的。 最后： 祝栏主和同学们新年快乐！

1、不抛。返回null-123123784378-aldjf780。从功能上讲，函数是生成logtraceid，用于给记录加id，便于查找日志。返回null不影响定位问题，同时程序不会蹦。 2、上抛，到generate中处理。 3、返回空串 4、返回空串

Go语言函数返回的时候分正确值、错误值，比较简单

对于今天课堂留的作业，我采用了统一的思路—能用异常解决的都用异常解决。 1.对于 generate() 函数，如果本机名获取失败，函数返回什么？这样的返回值是否合理？ 答：抛出异常，这是一个无法恢复的情况，打断正常的处理流程并进入异常逻辑处理模块 2. 对于 getLastFiledOfHostName() 函数，是否应该将 UnknownHostException 异常在函数内部吞掉（try-catch 并打印日志）？还是应该将异常继续往上抛出？如果往上抛出的话，是直接把 UnknownHostException 异常原封不动地抛出，还是封装成新的异常抛出？ 答：不应该内部吞掉，应该抛出到上层做统一的异常处理，这里是个单一的模块，不需要再封装 3. 对于 getLastSubstrSplittedByDot(String hostName) 函数，如果 hostName 为 NULL 或者是空字符串，这个函数应该返回什么？ 答：抛出异常，异常消息是—hostName为NULL或空字符串 4. 对于 generateRandomAlphameric(int length) 函数，如果 length 小于 0 或者等于 0，这个函数应该返回什么？ 答：抛出异常，异常消息是—参数不合法

我的领导告诉我，代码稳定是第一位的，如果线上代码没有出错，即便代码写得很烂，都是不允许去修改的，一个标点一个符号都不能修改，更别说小步重构了。所以可以理解为什么有的公司代码永远都是4、5年前的样子，不去动它了。