php中大量使用die或exit是否有弊端？
die 或 exit，除了可读性方面是否有其他弊端？
回复内容：
php 中大量使用 die 或 exit，除了可读性方面是否有其他弊端？
我觉得 die()/exit() 主要是影响程序的设计，也就是影响可读性和未来的可维护性。我自己是坚决抵制无脑使用 die()/exit() 的。
在 php 引入异常机制之前， die()/exit() 是仅有的提前退出程序的方法，用一用还凑合。但有了异常机制之后，应该学习 java 的设计思路：业务的错误用返回值返回，无法处理的请求抛异常。这样的设计保证了调用者无论如何都有足够的控制权，从而让整个系统是健壮的。
在设计工具类和工具函数时，die()/exit() 应该严令禁止，因为它们无权决定整个程序的生死。
在写一个具体业务脚本时，die()/exit() 仅在需要向 shell 返回状态码或者确实确定业务已经结束的情况下使用，其他情况最好禁止使用。
die()和exit()都是表示在这里就自然结束，我觉得很正常啊，为什么会有可读性的问题？私以为超长的逻辑嵌套和多重include更有可能造成你所谓的可读性的问题。
exit和die是人为结束脚本运行，顾名思义，可读性肯定没有问题的。
性能方面，直接结束脚本运行，对性能是有益无害。
如果非要说弊端，那我认为是：本来应该用return的时候却使用了exit，可能脚本提前退出，造成功能上的问题。不过，我认为这是写代码的人的问题，和语法结构没有关系。
所以，该用就用吧，放心大胆的用，提供出来就是让人使用的。
对于程序代码书写来说，我同意公子 @公子 die 和 exit 就是程序结束。
但是对于函数和库的设计来说，我觉得不应该使用这两个，而是使用 return。因为一个函数的调用，不应该将整个程序给停止了（OMG，这个函数的权限也太大了点儿吧）。不管这个函数是正确调用，还是出现问题了，都应该通知他的调用者，方法当然是通过 return 了。
还没有遇到过性能上的问题，但是如果你使用trigger_error()函数来替代die()，你的代码在处理错误上会更具优势，对于客户程序员来说更易于处理错误。
下面是是我转发的一篇文章，你可以看看：http://blog.csdn.net/yipiankongbai/article/details/17568223