有一些通用的机制，语言可以允许一个方法退出而不返回值，并unwind到下一个“catch”块:

Have the method examine the stack frame to determine the call site, and use the metadata for the call site to find either information about a try block within the calling method, or the location where the calling method stored the address of its caller; in the latter situation, examine metadata for the caller's caller to determine in the same fashion as the immediate caller, repeating until one finds a try block or the stack is empty. This approach adds very little overhead to the no-exception case (it does preclude some optimizations) but is expensive when an exception occurs. Have the method return a "hidden" flag which distinguishes a normal return from an exception, and have the caller check that flag and branch to an "exception" routine if it's set. This routine adds 1-2 instructions to the no-exception case, but relatively little overhead when an exception occurs. Have the caller place exception-handling information or code at a fixed address relative to the stacked return address. For example, with the ARM, instead of using the instruction "BL subroutine", one could use the sequence: adr lr,next_instr b subroutine b handle_exception next_instr:

要正常退出，子例程只需执行bx lr或pop {pc};在异常退出的情况下，子例程将在执行返回之前从LR中减去4，或者使用sub LR，#4,pc(取决于ARM的变化，执行模式等)。如果调用者没有被设计为适应它，这种方法将会非常严重地故障。

A language or framework which uses checked exceptions might benefit from having those handled with a mechanism like #2 or #3 above, while unchecked exceptions are handled using #1. Although the implementation of checked exceptions in Java is rather nuisancesome, they would not be a bad concept if there were a means by which a call site could say, essentially, "This method is declared as throwing XX, but I don't expect it ever to do so; if it does, rethrow as an "unchecked" exception. In a framework where checked exceptions were handled in such fashion, they could be an effective means of flow control for things like parsing methods which in some contexts may have a high likelihood of failure, but where failure should return fundamentally different information than success. I'm unaware of any frameworks that use such a pattern, however. Instead, the more common pattern is to use the first approach above (minimal cost for the no-exception case, but high cost when exceptions are thrown) for all exceptions.

你可能会对Common Lisp的条件系统感兴趣，它是对异常的一种概括。因为你可以以一种可控的方式展开堆栈，也可以得到“重启”，这非常方便。

这与其他语言的最佳实践没有太大关系，但它向您展示了在您正在考虑的方向上，使用一些设计思想可以完成什么。

当然，如果您像溜溜球一样在堆栈上上下跳动，仍然存在性能考虑，但这比大多数捕获/抛出异常系统所体现的“哦，糟糕，让我们离开”这种方法要普遍得多。

我觉得你的例子没有错。相反，忽略被调用函数抛出的异常是错误的。

在JVM中，抛出异常的代价并不高，只需使用新的xyzException(…)创建异常，因为后者涉及堆栈遍历。因此，如果您预先创建了一些异常，您可以多次抛出它们而无需付出任何代价。当然，这种方式不能将数据与异常一起传递，但我认为无论如何这都是一件糟糕的事情。

一般来说，在低级别处理异常本身并没有什么问题。异常是一个有效的消息，它提供了一个操作为什么不能执行的很多细节。如果你能接受，你就应该接受。

一般来说，如果你知道有很高的失败概率，你可以检查…你应该去检查一下…即if(obj != null) obj.method()

在你的情况下，我对c#库不够熟悉，不知道date time是否有一种简单的方法来检查时间戳是否越界。如果是，只需调用If (.isvalid(ts)) 否则，您的代码基本上没问题。

所以，归根结底，这取决于哪种方式可以创建更干净的代码……如果防止预期异常的操作比处理异常更复杂;那么你就有我的权限来处理异常，而不是到处创建复杂的守卫。

我的经验法则是:

如果您可以做任何事情来从错误中恢复，捕获异常 如果这个错误是很常见的(例如。用户尝试使用错误的密码登录)，使用returnvalues 如果您不能做任何事情来从错误中恢复，那么就让它不被捕获(或者在主捕获器中捕获它，以半优雅地关闭应用程序)

我认为异常的问题纯粹是从语法的角度来看的(我非常确定性能开销是最小的)。我不喜欢到处都是尝试块。

举个例子:

try
{
   DoSomeMethod();  //Can throw Exception1
   DoSomeOtherMethod();  //Can throw Exception1 and Exception2
}
catch(Exception1)
{
   //Okay something messed up, but is it SomeMethod or SomeOtherMethod?
}

. .另一个例子是，当你需要使用工厂将一些东西赋值给一个句柄时，该工厂可能会抛出异常:

Class1 myInstance;
try
{
   myInstance = Class1Factory.Build();
}
catch(SomeException)
{
   // Couldn't instantiate class, do something else..
}
myInstance.BestMethodEver();   // Will throw a compile-time error, saying that myInstance is uninitalized, which it potentially is.. :(

就我个人而言，我认为你应该为罕见的错误条件(内存不足等)保留异常，而使用returnvalues(值类，结构或枚举)来进行错误检查。

希望我正确理解了你的问题:)

Josh Bloch在《Effective Java》中广泛地讨论了这个主题。他的建议很有启发性，也适用于。net(细节除外)。

特别地，例外应用于特殊情况。原因主要与可用性有关。对于一个给定的方法，要最大限度地使用，它的输入和输出条件应该受到最大限度的约束。

例如，第二种方法比第一种方法更容易使用:

/**
 * Adds two positive numbers.
 *
 * @param addend1 greater than zero
 * @param addend2 greater than zero
 * @throws AdditionException if addend1 or addend2 is less than or equal to zero
 */
int addPositiveNumbers(int addend1, int addend2) throws AdditionException{
  if( addend1 <= 0 ){
     throw new AdditionException("addend1 is <= 0");
  }
  else if( addend2 <= 0 ){
     throw new AdditionException("addend2 is <= 0");
  }
  return addend1 + addend2;
}

/**
 * Adds two positive numbers.
 *
 * @param addend1 greater than zero
 * @param addend2 greater than zero
 */
public int addPositiveNumbers(int addend1, int addend2) {
  if( addend1 <= 0 ){
     throw new IllegalArgumentException("addend1 is <= 0");
  }
  else if( addend2 <= 0 ){
     throw new IllegalArgumentException("addend2 is <= 0");
  }
  return addend1 + addend2;
}

无论哪种情况，都需要检查以确保调用者正确地使用了您的API。但在第二种情况下，您需要它(隐式地)。如果用户没有读取javadoc，软异常仍然会被抛出，但是:

你不需要记录它。 你不需要测试它(取决于你的攻击性有多强 单元测试策略是)。 您不需要调用者处理三个用例。

最基本的一点是，异常不应该用作返回代码，很大程度上是因为你不仅让你的API变得复杂了，还让调用者的API变得复杂了。

当然，做正确的事情是有代价的。代价是每个人都需要理解他们需要阅读和遵循文档。希望是这样。