在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
前几天在博问中看到一个问题——Response.End()后,是否停止执行?MVC与WebForm不一致。看到LZ的描述后,虽然奇怪于为何用Response.End()而不用return方式去控制流程,但基于自己以往的认识,还是回答了说需要return。 因为以往的开发过程中,虽然没有用过Response.End()的方式像LZ所说地那样“方便地从多层调用中退出”,但是始终是认为Response.End()是不能终止其后代码执行的,思维路线大概是:Response.End()只是结束了HTTP返回流的写入,但是代码依然没有return啊,例如Page_Load中使用了Response.End(),但是这个方法并没有被跳出/终止。 之后LZ编辑了问题,继续提到了问题没有解决,又附带了伪代码希望大家帮忙改进书写方式。直到此时,由于自己的思维惯性,我依然我没有去写DEMO去验证对比webform和mvc下的Response.End(),简单地用主动throw new Exception的方式写出了MVC下“好看一点”的代码。 之后在回复中,LZ再次重复了Response.End()确实在webform和mvc中存在差异,我抱着试一试地心态测了一个疗程。真的有点吃惊,Reponse.End()在webfrom和ASP.NET MVC下的表现确实是不同的! ASP.NET MVC代码: public ActionResult Index() { Method0(); Method1(); Method2(); Response.Write("All methods success."); return View("I don't think so."); } private void Method0() { Debug.WriteLine("Method 0 process..."); bool flag = true; if (!flag) { Response.Write("Method 0 failure."); Response.End(); } } private void Method1() { Debug.WriteLine("Method 1 process..."); bool flag = false; if (!flag) { Response.Write("Method 1 failure."); Response.End(); } } private void Method2() { Debug.WriteLine("Method 2 process..."); bool flag = false; if (!flag) { Response.Write("Method 2 failure."); Response.End(); } } web页面显示: 调试信息输出: Response.End()后的代码继续执行,这与之前的认识是没有出入的,接下来看webform。 Webform代码: protected void Page_Load(object sender, EventArgs e) { Method0(); Method1(); Method2(); Response.Write("All methods success."); } private void Method0() { Debug.WriteLine("Method 0 process..."); bool flag = true; if (!flag) { HttpContext.Current.Response.Write("Method 0 failure."); System.Web.HttpContext.Current.Response.End(); } } private void Method1() { Debug.WriteLine("Method 1 process..."); bool flag = false; if (!flag) { HttpContext.Current.Response.Write("Method 1 failure."); System.Web.HttpContext.Current.Response.End(); } } private void Method2() { Debug.WriteLine("Method 2 process..."); bool flag = true; if (!flag) { HttpContext.Current.Response.Write("Method 2 failure."); System.Web.HttpContext.Current.Response.End(); } } web页面输出: 调试信息: web页面的输出一致,调试窗口那里可是大不一样。webform并未接着执行Response.End()后的代码,因为抛出了一个ThreadAbortException异常。这时候,我首先想到的是ASP.NET MVC下的Response对象类型是否和ASP.NET不同,导致他们的处理方式不同。 后来发现虽然ASP.NET MVC中的Response类型是HttpResponseBase,但是显式地去调用System.Web.Context.Current.Response.End()结果依旧。通过Reflector查看ASP.NET MVC下HttpResponseBase的实现类HttpResponseWrapper,End方法的实现如图,this_httpResponse是HttpResponse的私有变量。 查到这儿思路一度中断,只好回头去对比调试信息中的表现,从ThreadAbortException这个异常入手,发现在ASP.NET MVC中先调用Response.End(),再调用Thread.CurrentThread.Abort()可以达到webform下调用Response.End()的效果。当然其他异常也能模拟,但是此时发现了一个小问题,就是抛出普通异常的时候和抛出ThreadAbortException异常略有不同。 普通异常的弹出窗口: 调试信息输出: ThreadAbortException异常没有弹出那个窗口,调试信息中也多了一条信息。 是由于ThreadAbortException是SystemException(系统异常)被特殊对待了吗? 这只是一个衍生出来的疑问,继续刚才的问题,用ThreadAbortException和ASP.NET MVC作为关键字去google搜索,在Will保哥的博客中得到了解答! 经过保哥的指点,通过Reflector去查看源码,证实了是_timeoutState的作用。 HttpResponse.End中代码: IsInCancellablePeriod属性: 问题得到了解决!~但是我还有一个小疑问,也就是从Reflector中看到End方法的源码,IsInCancellablePeriod是bool类型,但是却判断是否等于null。这怎么也是不合适的吧,是Reflector的解析错误还是其他原因导致的呢? |
请发表评论