Kra*_*zzy 10 c# asp.net asp.net-mvc exception-handling
最近,我发现自己与我的老板在我们的网络应用程序(ac#asp.net MVC应用程序)中处理异常有很多争论.
对话基本上是这样的:
老板:"我们的程序有问题,客户端x的数据库今天关闭,每个人都看到错误页面."
我:"大多数应用程序中的每个页面都使用数据库(错误页面除外),除了显示错误页面之外没有其他合理的选择."
老板:"我们的应用程序应该更具弹性 - 应用程序中不需要数据库访问的部分仍然可以运行."
通常情况下,情况就像这样极端,但有时我们遇到的情况是我们正在与另一个服务集成,我们仍然可以安全地显示页面的其他部分,或者完成操作,尽管有一些烦人的代码作为后面的部分代码需要稍后使用可能失败的操作结果.如果有许多可能的失败点,这可能会变成一些非常难以管理的代码.
一般来说,对于"普通"Web应用程序(不是任务关键等等),"好"开发人员花多少时间来尝试使其代码具有足够的弹性来处理这些情况.我的老板似乎认为代码应该能够处理几乎任何情况(你不能只捕获异常吗？).当有许多可能的失败点时,我不明白这是多么经济.
当主数据库(即支持99%页面的数据库)关闭时,大部分数据驱动的大多数应用都被重定向到自定义错误页面.(你确实希望向他们展示自定义屏幕,而不仅仅是让他们获得服务器错误页面)
对于外部服务,如点击SMTP服务器或未被应用程序其余部分使用的数据库,我们通常会在其周围设置代码,如果服务/数据库关闭/无法访问,则只显示页面反馈.
它确实取决于客户端/利益相关者,只需确定在数据库关闭时他们想要发生什么,并为他们做.这需要时间,但它不应该导致无法维护的应用程序或任何其他编码恐怖.
| 归档时间： |
|
| 查看次数： |
554 次 |
| 最近记录： |