工程之殇

今天晚上的心路历程好让人泄气。

继续揣摩laravel项目中ValidationException的设计，看到里面的status，觉得好奇怪，为什么是叫status，不是直接把code设置一下呢？然后想想，好像也对，code是异常的代码，而status是http response的代码，两个不应该混为一谈。

接下来我想看下既然ValidationException没有设置code，那laravel中是怎么做到在渲染的时候把http response statuscode 设置为status的。然后就看到了render里面。

第一次看到这个代码，恶心坏了，这个分支的结构，真是太恶心了。然而琢磨了几个小时之后，直到写这篇文章的时候，我有种错觉，我已经把这坨shi吃下去了...

首先我想着是不是能优化下这个函数，是不是能把这里的渲染逻辑放到exception中呢？嗯，好像很完美。但是想想，不对啊。。。我定义一个异常的时候还需要定义好它的渲染方式，定义好它的json输出，html输出？明显不好。。。好，我只能接受在一个大类handler.php里面统一作处理。

其次我想，是不是可以再定义一个基类，让所有的类继承这个类。这里几个类最好的可能就是HttpResponse了。然后其他两个都继承这个类？然后在这个基类里面写一些逻辑？不对啊。。。不管你这个基类是什么，它还是一个异常，不应该在这个异常里面做这么复杂的事情啊。同上。而且，都继承这个类，子类里面也要有各种实现。。。不妥不妥。

好，那么我整理下handler类可好，封装一个函数，把所有的异常都进行遍历可好。但是这个方法可能就是二维的了，request是否json，和异常类型，两个纬度。那么，又是一个很恶心的函数。

呵呵，总而言之，好像没有最优美的解决方案了。遂放弃优化这块。

想想，这个明显是作者的设计不足。设计不够有扩展性。我又详细看了下laravel的异常，几个很大的问题：

1 异常继承随便继承，没有收口，以后要做统一处理，只能一个个遍历处理。有的继承Exception，有的继承Sysforny的Exception，有的继承Responseable接口。。。各种混乱。

2 输出格式没有统一。各种不同的异常需要不同的输出格式，再加上是否调试模式，这里已经有好几个分支了。没有考虑过统一的格式过滤。

哎，优雅的laravel内部还是很多问题的。这个地方，不是很优雅。但是，只能说，介于历史包袱，它只能做到这样了。

于是我想到我们平时的业务工程，不就是和这种项目一样么，越来越久之后，背上承重的壳，也就这么痛苦不堪了。so，这就是工程之殇。

于是，我只能啥都不改，悻悻地上床睡觉。又是一个胡思乱想晚上。