首先，免责声明：我在其他语言方面有经验，但仍在学习C#的细微差别。
接下来讲问题... 我正在查看一些代码，它使用try/catch块的方式让我感到担忧。当调用解析例程时，程序员没有返回错误代码，而是使用了以下逻辑：
catch (TclException e) {
throw new TclRuntimeError("unexpected TclException: " + e.Message,e);
}
这个错误被调用者捕获并抛出相同的错误...
...由调用者捕获，抛出相同的错误...
...以此类推，直到回溯约6层。
我是否正确地认为所有这些catch/throw块都会导致性能问题，还是这是在C#下合理的实现？
无论使用何种语言，这都是一种糟糕的设计。
异常被设计成在你可以处理它们的层次上捕获。仅仅为了再次抛出异常是完全没有意义的浪费时间（这还会导致丢失有关原始错误位置的宝贵信息）。
显然，编写该代码的人曾经使用错误代码，然后转而使用异常，但实际上并不理解它们的工作原理。如果某个级别没有catch，那么异常会自动“冒泡”到栈上方。
此外，请注意，异常仅用于非常规情况，即永远不应该发生的事情。它们不应该用于正常有效性检查的替代（例如，不要捕获除以零的异常；先检查除数是否为零）。
根据msdn:Performance Tips and Tricks，在真正抛出异常之前，您可以毫不担心地使用try和catch而不会有任何性能问题。
抛出异常（而不是捕获）是昂贵的。
除非你要做一些有用的事情（例如将其转换为更有用的异常、处理错误），否则不要放置一个 catch 块。
仅重新抛出异常（不带参数的 throw 语句），甚至更糟的是，抛出与刚刚捕获的相同的对象，肯定是错误的做法。
编辑：为避免歧义：
重新抛出：
catch (SomeException) {
throw;
}
从先前的异常对象创建异常，其中所有运行时提供的状态（特别是堆栈跟踪）都被覆盖：
catch (SomeException e) {
throw e;
}
后一种情况是一种毫无意义的丢弃异常信息的方式。而在 catch 块中抛出异常之前没有任何内容更是没有意义的。这可能会更糟：
catch (SomeException e) {
throw new SomeException(e.Message);
}
这会丢失几乎所有有用的状态信息，包括最初抛出的内容。
本身并不可怕，但需要注意嵌套的层数。
可以接受的使用情况如下：
我是一个较低级别的组件，可能会遇到多种不同的错误，但我的消费者只关心特定类型的异常。因此，我可以这样做：
catch(IOException ex)
{
throw new PlatformException("some additional context", ex);
}
try
{
component.TryThing();
}
catch(PlatformException ex)
{
// handle error
}
Try / Catch / Throw 是比较慢的 - 更好的实现方式是在捕获异常之前先检查其值，但如果你绝对无法继续执行，最好的方法是只在必要时抛出和捕获异常。否则，检查和记录日志会更有效率。
如果每个堆栈层只是以相同的信息和相同的类型重新抛出异常，而没有添加任何新内容，那么这完全是荒谬的。
如果这种情况发生在独立开发的库之间的边界上，那就可以理解了。有时库的作者想要控制从他们的库中逃逸的异常，以便他们以后可以更改实现，而不必弄清楚如何模拟先前版本的异常抛出行为。
在任何情况下捕获并重新抛出都是一个不好的主意，除非有非常好的理由。这是因为一旦找到一个catch块，所有在throw和catch之间的finally块都会被执行。只有当异常可以恢复时才应该发生这种情况。在这种情况下，这是可以接受的，因为特定类型被捕获，所以代码的作者（希望如此）知道他们可以安全地撤消对特定异常类型的任何内部状态更改。
因此，这些try/catch块在设计时可能会产生成本-它们使程序变得混乱。但在运行时，只有在抛出异常时才会产生显着的成本，因为将异常传输到堆栈上变得更加复杂。
例外处理很慢，请尽量不要使用。
请看我这里给出的答案。
基本上，CLR团队的Chris Brumme说它们是作为SEH异常实现的，所以当它们被抛出时会受到很大的打击，并且必须承受它们通过操作系统堆栈冒泡所产生的惩罚。这是一篇优秀文章，深入探讨了抛出异常时发生的事情。例如：
有些人会声称异常不是问题，没有性能问题，通常是好事。这些人得到了很多的支持，但他们是错的。我曾经看到微软员工做出同样的声明（通常具有营销部门通常保留的技术知识），但从内部人士的角度来看，要谨慎使用。
古老的格言“异常只应用于特殊情况”对C#和其他任何语言都是正确的。