巧用Using跳过异常捕获

简介:

前言

    这里主要说一个使用using躲过异常的小技巧。

    我原来就遇到过类似的问题好几次了,也没想到办法,直接有一天,调试得实在受不了了,才认真想了以下的解决方案。


问题

    原来的代码是这样的:

public abstract class Command : RoutedUICommand
{
    private bool _isExecuting = false;

    public void Execute(CommandContext commandContext)
    {
        this._isExecuting = true;
        try
        {
            OnExecute(commandContext);
        }
        catch
        {
            throw;
        }
        finally
        {
            this._isExecuting = false;
        }
    }

    protected abstract void OnExecute(CommandContext commandContext);
}

    这是一个抽象的命令类,这里只贴出了这个问题的主要的逻辑:需要在OnExecute方法执行之前设置_isExecuting的值为true,然后执行OnExecute方法,然后不管是否出现异常,都在执行完毕后,设置为false。子类实现这个类实现OnExecute方法来编写自己真正的执行代码。这时比较麻烦的一个问题是:在代码编写阶段,当子类的OnExecute方法内部出现异常时,Visual Studio都会直接把错误给定在这个类上,如下:

子类:

private class ConcreteCommand : Command
{
    protected override void OnExecute(CommandContext commandContext)
    {
        int i = 0;
        int j = 100 / i;
        //.......
    }
}

出现异常:

image

    调试的过程中,无法直接定位到子类,当代码很多时,找实现这个基类的子类是很烦人的事。而且找到了它以后,打上断点,还得重新运行一遍来运行同样的bug路径。时间就是这样浪费的,调试得很崩溃……


解决

    需要重构了基类的代码,但是由于Execute方法的设置_isExecuting字段的逻辑不能改变,所以并不简单。灵光一闪,有了以下的实现:

public abstract class Command
{
    public void Execute(CommandContext commandContext)
    {
        this._isExecuting = true;
        using (this.__isExecuting)
        {
            OnExecute(commandContext);
        }
    }
    protected abstract void OnExecute(CommandContext commandContext);

    private bool _isExecuting
    {
        get
        {
            return this.__isExecuting.Value;
        }
        set
        {
            this.__isExecuting.Value = value;
        }
    }
    private IsExecutingWrapper __isExecuting = new IsExecutingWrapper();

    /// <summary>
    /// 原来的模式增加了调试的困难度。
    /// 添加这个方法方便调试。
    /// </summary>
    private class IsExecutingWrapper : IDisposable
    {
        private bool _value;
        public bool Value
        {
            get
            {
                return this._value;
            }
            set
            {
                this._value = value;
            }
        }

        #region IDisposable Members

        public void Dispose()
        {
            this._value = false;
        }

        #endregion
    }
}

    成功解决:

image


后话

    因为我不只一次遇到过这个问题,所以我猜测肯定还会有朋友会遇到同样的问题。所以就把这个小问题冒昧的发在了首页。希望和大家分享。另外,如果你有更好的方法,可以用力的拍我。 :)


本文转自BloodyAngel博客园博客,原文链接:http://www.cnblogs.com/zgynhqf/archive/2009/12/17/1626658.html,如需转载请自行联系原作者

相关文章
|
6月前
【BUG】循环中重复使用对象一定要注意
【BUG】循环中重复使用对象一定要注意
|
1月前
|
C语言
20.C语言:用continue语句提前终止循环
20.C语言:用continue语句提前终止循环
14 0
|
4月前
|
数据库连接 Go 开发者
避免defer陷阱:拆解延迟语句,掌握正确使用方法
避免defer陷阱:拆解延迟语句,掌握正确使用方法
|
8月前
面试时通常让你默写的运行时异常与编译时异常举例
面试时通常让你默写的运行时异常与编译时异常举例
|
10月前
|
Java 测试技术 API
开发小技巧系列 - 如何避免NPE,去掉if...else(四)
利用optional来处理各种IF-ELSE的判断
78 0
因为一道题,我把 try-catch-finally 的细节都整理了一遍(1500字)
原因:return i++; 在内部是可以分为三步,① int tmp = i; ② i += 1; ③ return tmp;
67 0
因为一道题,我把 try-catch-finally 的细节都整理了一遍(1500字)
你真的明白关于迭代器的方法、使用异常、并发修改异常介绍嘛?
关于迭代器的方法、使用异常、并发修改异常介绍的使用
101 0
你真的明白关于迭代器的方法、使用异常、并发修改异常介绍嘛?
|
API 开发者
这些地方容易出错 | 学习笔记
简介:快速学习这些地方容易出错
78 0
这些地方容易出错 | 学习笔记
|
消息中间件 监控 前端开发
生产环境一次诡异的NPE问题,反转了4次
生产环境一次诡异的NPE问题,反转了4次
生产环境一次诡异的NPE问题,反转了4次