c# - 如果需要，使用许多业务异常是否正常？

Question

定义和抛出自定义异常是否是一种好的做法，即使应用程序需要大量异常也是如此？

• EntityNotFoundException
• EntityAlreadyExistsException
• EntityNotUniqueException
• EntityNotAddedException
• EntityNotUpdatedException
• EntityNotDeletedException
• QuizOverException
• QuizExpiredException
• TableAlreadyBookedException
• EndDateMustBeGreaterThanStartDateException

我尝试为这些示例异常名称命名，以尽可能准确地描述它们的用途。我希望他们能了解我想问的问题。

不要将您的想象力局限于这些异常(exception)情况，而是应用程序生命周期中可能出现的所有情况。同时考虑 CRUD 和业务异常。

我知道抛出和捕获异常在性能方面是一个代价高昂的过程，但它们是否提供了一种更优雅的应用开发方式？

• 抛出 EntityNotFoundException 而不是编写 if 语句来检查实体是否为 null 不是更好吗？
• 抛出一个 EntityAlreadyExistsException 而不是编写一个额外的 if 语句来调用一个方法来检查具有给定 ID 的实体是否已经存在的方法不是更好吗？
• 抛出 EntityNotAddedException 而不是检查指定事务是否成功的 bool 类型的返回值不是更好吗？如果我们想返回一个对象怎么办？

我觉得答案会像“你不应该使用 EntityNotFoundException 而是检查是否为 null，但你应该使用 EntityAlreadyExistsException”，“没有 chalice ".

我想知道这样做的优雅方式是什么？

Answer 1

请记住，异常(exception)情况应该代表异常(exception)情况，您所有的问题只能真正得到答案 - 视情况。

您打算何时何地抛出特定异常的上下文自然会决定它是否有意义。例如，如果您尝试检索一个应该存在但实际上不存在的实体，那么抛出一个EntityNotFoundException 将被认为是合适的，因为我们现在有一个异常 情况。另一方面，如果您在创建新实体之前检查该实体是否已经存在，那么您可能会争辩说，因为我们知道该实体有可能存在或可能不存在，所以这并不是真正的异常(exception)情况。

就像我说的，这真的取决于情况的上下文和你的应用程序的性质，你是否应该抛出异常，但是，你不想最终做的一件事是控制程序流有异常(exception)。

为了帮助区分何时适合使用异常与业务逻辑，只需问自己“这种特定情况有效吗？”或者换句话说“是否适合应用程序发现自己处于这种状态？”。如果答案是肯定的，使用逻辑来控制应用程序的流程并处理这种情况，否则你想抛出一个 Exception 来有效地中断程序流程并通知用户事情不是非常正确。