强制“结束”每当有相应的“开始”时就调用称呼

Question

假设我想执行一条规则：

每次在函数中调用“StartJumping()”时，都必须在返回之前调用“EndJumping()”。

当开发人员编写代码时，他们可能只是忘记调用 EndSomething - 所以我想让它更容易记住。

我只能想到一种方法来做到这一点：它滥用了“using”关键字：

class Jumper : IDisposable {
    public Jumper() {   Jumper.StartJumping(); }
    public void Dispose() {  Jumper.EndJumping(); }

    public static void StartJumping() {...}
    public static void EndJumping() {...}
}

public bool SomeFunction() {
    // do some stuff

    // start jumping...
    using(new Jumper()) {
        // do more stuff
        // while jumping

    }  // end jumping
}

有更好的方法来做到这一点吗？

Answer 1

本质上，问题是：

• 我有全局状态......
• 并且我想改变该全局状态......
• 但我想确保我将其改变回来。

您发现这样做时会很痛。我的建议是，与其试图找到一种减少痛苦的方法，不如尝试找到一种从一开始就不做痛苦的事情的方法。

我很清楚这有多难。当我们在 v3 中向 C# 添加 lambda 时，我们遇到了一个大问题。考虑以下问题：

void M(Func<int, int> f) { }
void M(Func<string, int> f) { }
...
M(x=>x.Length);

我们到底如何成功绑定它？好吧，我们要做的就是尝试两者（x 是 int，或 x 是 string），看看哪一个（如果有的话）会给我们带来错误。那些没有给出错误的将成为重载解决方案的候选者。

编译器中的错误报告引擎是全局状态。在 C# 1 和 2 中，从来没有出现过这样的情况：我们不得不说“绑定整个方法体以确定它是否有任何错误但不报告错误”。毕竟，在这个程序中，您不想想要收到错误“int 没有名为 Length 的属性”，您希望它发现这一点，记下它，而不是报告它。

所以我所做的正是你所做的。开始抑制错误报告，但不要忘记停止抑制错误报告。

太可怕了。我们真正应该做的是重新设计编译器，以便错误是语义分析器的输出，而不是编译器的全局状态。然而，很难将其贯穿数十万行依赖于全局状态的现有代码。

无论如何，还有其他事情要考虑。您的“使用”解决方案具有在引发异常时停止跳转的效果。 这是正确的做法吗？可能不是。毕竟，抛出了意外的、未处理的异常。整个系统可能非常不稳定。在这种情况下，您的内部状态不变量可能实际上都不是不变的。

这样看：我改变了全局状态。然后我遇到了一个意外的、未处理的异常。我知道，我想我会再次改变全局状态！那会有帮助的！看起来是一个非常非常糟糕的主意。

当然，这取决于全局状态的突变是什么。如果它是“再次开始向用户报告错误”，就像在编译器中一样，那么对于未处理的异常，正确的做法是再次开始向用户报告错误：毕竟，我们'我们需要报告编译器刚刚出现未处理的异常的错误！

另一方面，如果全局状态的突变是“解锁资源并允许不可信代码观察和使用它”，那么自动解锁它可能是一个非常糟糕的想法。这种意外的、未处理的异常可能是对您的代码进行攻击的证据，攻击者非常希望您能够解锁对全局状态的访问，因为它处于易受攻击的、不一致的形式。

Answer 2

我不同意埃里克的观点：何时这样做或不这样做取决于具体情况。有一次，我正在重新设计我的大型代码库，以包含围绕对自定义图像类的所有访问的获取/释放语义。图像最初分配在不可移动的内存块中，但我们现在能够将图像放入允许移动的块中（如果尚未获取它们）。在我的代码中，内存块滑过解锁状态是一个严重的错误。

因此，强制执行这一点至关重要。我创建了这个类：

public class ResourceReleaser<T> : IDisposable
{
    private Action<T> _action;
    private bool _disposed;
    private T _val;

    public ResourceReleaser(T val, Action<T> action)
    {
        if (action == null)
            throw new ArgumentNullException("action");
        _action = action;
        _val = val;
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    ~ResourceReleaser()
    {
        Dispose(false);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed)
            return;

        if (disposing)
        {
            _disposed = true;
            _action(_val);
        }
    }
}

它允许我创建这个子类：

public class PixelMemoryLocker : ResourceReleaser<PixelMemory>
{
    public PixelMemoryLocker(PixelMemory mem)
        : base(mem,
        (pm =>
            {
                if (pm != null)
                    pm.Unlock();
            }
        ))
    {
        if (mem != null)
            mem.Lock();
    }

    public PixelMemoryLocker(AtalaImage image)
        : this(image == null ? null : image.PixelMemory)
    {
    }
}

这又让我编写这个代码：

using (var locker = new PixelMemoryLocker(image)) {
    // .. pixel memory is now locked and ready to work with
}

这完成了我需要的工作，快速搜索告诉我我在 186 个地方需要它，我可以保证永远不会失败解锁。我必须能够做出这样的保证 - 否则可能会冻结我的客户端堆中的一大块内存。我不能那样做。

然而，在我处理 PDF 文档加密的另一种情况下，所有字符串和流都在 PDF 字典中加密，除非它们没有加密。真的。在极少数边缘情况下，加密或解密字典是不正确的，因此在流式传输对象时，我会这样做：

if (context.IsEncrypting)
{
    crypt = context.Encryption;
    if (!ShouldBeEncrypted(crypt))
    {
        context.SuspendEncryption();
        suspendedEncryption = true;
    }
}
// ... more code ...
if (suspendedEncryption)
{
    context.ResumeEncryption();
}

那么为什么我选择这种方法而不是 RAII 方法呢？好吧，在...more代码中发生的任何异常...都意味着你已经死在水里了。没有恢复。不可能恢复。您必须从头开始，并且需要重建上下文对象，因此无论如何它的状态都是固定的。相比之下，我只需要执行此代码 4 次 - 发生错误的可能性比内存锁定代码要少得多，并且如果我将来忘记了一个，生成的文档将立即被破坏（失败快速地）。

因此，当您绝对必须进行括号内的调用并且不能失败时，请选择 RAII。
如果其他做法很简单，请不要费心使用 RAII。

Answer 3

如果您需要控制作用域操作，我将添加一个方法，该方法采用 Action 来包含跳线实例上所需的操作：

public static void Jump(Action<Jumper> jumpAction)
{
    StartJumping();
    Jumper j = new Jumper();
    jumpAction(j);
    EndJumping();
}

Answer 4

在某些情况下（即当所有操作都可以在最后发生时）有效的另一种方法是创建一系列具有流畅接口和一些最终 Execute() 方法的类。

var sequence = StartJumping().Then(some_other_method).Then(some_third_method);
// forgot to do EndJumping()
sequence.Execute();

Execute() 可以向后链接并强制执行任何规则（或者您可以在构建开始序列时构建结束序列）。

与其他技术相比，该技术的一个优点是您不受范围规则的限制。例如，如果您想基于用户输入或其他异步事件构建序列，您可以这样做。

Answer 5

Jeff，

您想要实现的目标通常被称为面向方面编程（ AOP）。在 C# 中使用 AOP 范例进行编程并不容易，也不可靠……目前为止。 CLR 和 .NET 框架中直接内置了一些功能，使 AOP 在某些狭窄的情况下成为可能。例如，当您从 ContextBoundObject 派生类时，您可以使用 ContextAttribute 在 CBO 实例上的方法调用之前/之后注入逻辑。您可以在此处查看如何完成此操作的示例。

派生 CBO 类既烦人又具有限制性——而且还有另一种选择。您可以使用 PostSharp 等工具将 AOP 应用于任何 C# 类。 PostSharp 比 CBO 灵活得多，因为它本质上在编译后步骤中重写您的 IL 代码。虽然这看起来有点可怕，但它非常强大，因为它允许您以几乎任何您可以想象的方式编织代码。以下是基于您的使用场景构建的 PostSharp 示例：

using PostSharp.Aspects;

[Serializable]
public sealed class JumperAttribute : OnMethodBoundaryAspect
{
  public override void OnEntry(MethodExecutionArgs args) 
  { 
    Jumper.StartJumping();
  }     

  public override void OnExit(MethodExecutionArgs args) 
  { 
    Jumper.EndJumping(); 
  }
}

class SomeClass
{
  [Jumper()]
  public bool SomeFunction()  // StartJumping *magically* called...          
  {
    // do some code...         

  } // EndJumping *magically* called...
}

PostSharp 通过重写已编译的 IL 代码以包含运行您在 JumperAttribute 类中定义的代码的指令来实现神奇 ' OnEntry 和 OnExit 方法。

在您的情况下，PostSharp/AOP 是否是比“重新调整用途”using 语句更好的替代方案，我不清楚。我倾向于同意 @Eric Lippert 的观点，即 using 关键字混淆了代码的重要语义并强加了using 块末尾的 } 符号的副作用和语义 - 这是意外的。但这与将 AOP 属性应用于代码有什么不同吗？它们还将重要的语义隐藏在声明性语法后面……但这就是 AOP 的要点。

我完全同意 Eric 的观点是，重新设计代码以避免这样的全局状态（如果可能）可能是最好的选择。它不仅避免了强制正确使用的问题，而且还可以帮助避免未来的多线程挑战 - 全局状态非常容易受到这种挑战。

Answer 6

我实际上并不认为这是对 using 的滥用；我在不同的上下文中使用这个习语并且从未遇到过问题......特别是考虑到 using 只是一个语法糖。我使用它在我使用的第三方库之一中设置全局标志的一种方法是，以便在完成操作时恢复更改：

class WithLocale : IDisposable {
    Locale old;
    public WithLocale(Locale x) { old = ThirdParty.Locale; ThirdParty.Locale = x }
    public void Dispose() { ThirdParty.Locale = old }
}

请注意，您不需要在 using 子句中分配变量。这就足够了：

using(new WithLocale("jp")) {
    ...
}

我有点怀念 C++ 的 RAII 习惯用法，其中总是调用析构函数。我猜，using 是 C# 中最接近的。

Answer 7

我们几乎完全按照您的建议在我们的应用程序中添加方法跟踪日志记录。无需进行 2 次日志记录调用，一次用于进入，一次用于退出。

Answer 8

拥有一个抽象基类会有帮助吗？基类中的方法可以调用 StartJumping()（子类将实现的抽象方法的实现），然后调用 EndJumping()。

Answer 9

我喜欢这种风格，并且当我想保证一些拆卸行为时经常实现它：通常它比 try-finally 读起来更干净。我认为您不应该费心声明和命名引用 j，但我确实认为您应该避免调用 EndJumping 方法两次，您应该检查它是否已被释放。并参考您的非托管代码注释：它是通常为此实现的终结器（尽管通常调用 Dispose 和 SuppressFinalize 来更快地释放资源。）

Answer 10

我已经对这里的一些答案发表了一些关于 IDisposable 是什么和不是什么的评论，但我会重申一点，IDisposable 是为了启用确定性清理，但是不保证确定性清理。即它不保证被调用，并且仅在与 using 块配对时才得到一定程度的保证。

// despite being IDisposable, Dispose() isn't guaranteed.
Jumper j = new Jumper();

现在，我不会评论您对 using 的使用，因为 Eric Lippert 在这方面做得更好。

如果您确实有一个不需要终结器的 IDisposable 类，我见过的用于检测人们何时忘记调用 Dispose() 的模式是添加一个在 DEBUG 版本中有条件编译的终结器，以便您可以每当调用终结器时都会记录一些内容。

一个现实的例子是一个类，它以某种特殊的方式封装了对文件的写入。因为 MyWriter 持有对 FileStream 的引用，而该文件流也是 IDisposable，所以出于礼貌，我们还应该实现 IDisposable。

public sealed class MyWriter : IDisposable
{
    private System.IO.FileStream _fileStream;
    private bool _isDisposed;

    public MyWriter(string path)
    {
        _fileStream = System.IO.File.Create(path);
    }

#if DEBUG
    ~MyWriter() // Finalizer for DEBUG builds only
    {
        Dispose(false);
    }
#endif

    public void Close()
    {
        ((IDisposable)this).Dispose();
    }

    private void Dispose(bool disposing)
    {
        if (disposing && !_isDisposed)
        {
            // called from IDisposable.Dispose()
            if (_fileStream != null)
                _fileStream.Dispose();

            _isDisposed = true;
        }
        else
        {
            // called from finalizer in a DEBUG build.
            // Log so a developer can fix.
            Console.WriteLine("MyWriter failed to be disposed");
        }
    }

    void IDisposable.Dispose()
    {
        Dispose(true);
#if DEBUG
        GC.SuppressFinalize(this);
#endif
    }

}

哎哟。这相当复杂，但这正是人们看到 IDisposable 时所期望的。

该类除了打开一个文件之外甚至没有做任何事情，但这就是您使用 IDisposable 获得的效果，并且日志记录极其简化。

    public void WriteFoo(string comment)
    {
        if (_isDisposed)
            throw new ObjectDisposedException("MyWriter");

        // logic omitted
    }

终结器非常昂贵，并且上面的 MyWriter 不需要终结器，因此在 DEBUG 构建之外添加终结器是没有意义的。

Answer 11

使用 using 模式，我可以使用 grep (? 来查找可能存在问题的所有位置。

使用 StartJumping，我需要手动查看每个调用，以查明是否存在异常、返回、中断、继续、转到等可能导致 EndJumping 不被调用的可能性。

Answer 12

1. 我不认为你想让这些方法成为静态
2. 你需要检查处理是否已经调用了结束跳转。
3. 如果我再次调用开始跳跃会发生什么？

您可以使用参考计数器或标志来跟踪“跳跃”的状态。有些人会说 IDisposable 仅适用于非托管资源，但我认为这是可以的。否则，您应该将开始和结束跳转设为私有，并使用析构函数来配合构造函数。

class Jumper
{
    public Jumper() {   Jumper.StartJumping(); }
    public ~Jumper() {  Jumper.EndJumping(); }

    private void StartJumping() {...}
    public void EndJumping() {...}
}