"quot quot 应用程序中的应用服务器错误

下午三点十七分，我正盯着屏幕上的程序黄底黑字报错页面。那行字就横在浏览器中央，服务像一堵涂了警示漆的器错矮墙："/" 应用程序中的服务器错误。下面跟着一行小字——运行时错误。应用没了。程序就这些。服务没有堆栈跟踪，器错没有错误码，应用连个"请联系管理员"的程序客套话都省了。

这页面我熟。服务做网站这几年，器错它跟牛皮癣似的应用，隔三差五就来一趟。程序每次看到它，服务第一反应不是骂服务器，而是先骂自己：又忘了关自定义错误模式？还是web.config里那行<customErrors mode="Off"/>写错位置了？

说真的，ASP.NET这个报错页的设计堪称行为艺术。它把所有技术细节藏得严严实实，只给用户留一句"服务器错误"——这等于什么都没说。你问普通用户看到这页面什么感受？他们只会觉得这网站坏了，关掉走人。可对我们这些维护者来说，真正要命的是另一件事：生产环境里你根本看不到具体异常，只能翻事件日志，或者临时改配置把详细错误露出来。

我上个月就栽过一次。客户半夜打电话说后台登录页打不开，我远程一看，就是这个黄页。当时心里咯噔一下——昨天刚部署了新版本，数据库连接字符串改过。赶紧查日志，发现是连接池超时。但为什么超时？查了半天才发现，新代码里有个循环没释放SqlConnection，跑了三小时，连接池满了一百个，后面的请求全堵死了。

这类错误最坑的地方在于，它不像404那样直白——"页面不存在"你还能猜个大概。服务器错误是个黑箱，可能是代码崩了，可能是权限不够，也可能是IIS配置抽风。有一次我把一个静态HTML文件放进App_Code文件夹，整个站点直接罢工，报的就是这个错。谁能想到HTML文件会被当成C#代码编译？

后来我学乖了。部署前先在本地把customErrors关掉跑一遍，确认没有隐藏异常；上线后保留一个专门的错误日志页面，把未处理异常写进数据库。但话说回来，这黄页也不是全无用处——它至少提醒你一件事：服务器还活着，只是你的代码让它消化不良。

现在看到这个页面，我反而会松口气。至少不是502，不是连接被重置，不是DNS解析失败。那是另一种绝望——连服务器影子都摸不着的时候，你连改配置的机会都没有。

说到底，技术人跟这个黄页的关系就像跟感冒的关系——你知道它迟早要来，来了就对症下药，药到病除后继续过日子。但每次见面，还是忍不住想：微软就不能把这个页面设计得稍微友好点？哪怕多给个HTTP状态码也行啊。

(责任编辑：百科)