以下是需要考虑的事项的简短列表.虽然不全面，但我相信这些东西可以帮助您编写更好的代码.底线:不一定将异常处理视为邪恶.相反，在编写它们时，问问自己:我真正了解我正在解决的问题的程度如何?通常，这将帮助您成为更好的开发者.

Here's a short list of things to consider. While not comprehensive, I believe these things can help you write better code. Bottom line: Don't necessarily perceive exception handling as evil. Instead, when writing them, ask yourself: How well do I really understand the problem I am solving? More often than not, this will help you become a better developer.

1. 其他开发者能否阅读此内容?普通开发者能否合理地理解?示例:ServiceConnectionException 与令人困惑的 ServiceDisconnectedConnectionStatusException
2. 在抛出异常的情况下，情况如何异常?调用者必须做什么才能实现该方法?
3. 这个异常是致命的吗?如果它被捕获，真的可以用这个异常做任何事情吗?线程中止，内存不足......你不能做任何有用的事情.不要抓住它.
4. 异常是否令人困惑?假设您有一个名为 Car GetCarFromBigString(string desc) 的方法，它接受一个字符串并返回一个 Car 对象.如果该方法的主要用例是从该 string 生成一个 Car 对象，则不要在 Car 不能时抛出异常'不是由 string 决定的.相反，编写一个类似 bool TryGetCarFromBigString(string desc, out Car) 的方法.
5. 这是否可以轻松避免?我可以检查一些东西吗，比如说数组或变量的大小为空?

1. Will other developers be able to read this? Can it be reasonably understood by the average developer? Example: ServiceConnectionException vs. a confusing ServiceDisconnectedConnectionStatusException
2. In the case of throwing an exception, how exceptional is the circumstance? What does the caller have to do in order to implement the method?
3. Is this exception fatal? Can anything really be done with this exception if it is caught? Threads aborting, out of memory.. you can't do anything useful. Don't catch it.
4. Is the exception confusing? Let's say you have a method called Car GetCarFromBigString(string desc) that takes a string and returns a Car object. If the majority use-case for that method is to generate a Car object from that string, don't throw an exception when a Car couldn't be determined from the string. Instead, write a method like bool TryGetCarFromBigString(string desc, out Car).
5. Can this be easily prevented? Can I check something, let's say the size of an array or a variable being null?

为了代码可读性，让我们看一下您的上下文.

For code readability's sake, let's potentially take a look at your context.

bool IsServiceAlive()
{
   bool connected = false;  //bool is always initialized to false, but for readability in this context

   try
   {
      //Some check
      Service.Connect();
      connected = true;
   }
   catch (CouldNotConnectToSomeServiceException)
   {
      //Do what you need to do
   }

   return connected;
}

//or
void IsServiceAlive()
{
   try
   {
      //Some check
      Service.Connect();
   }
   catch (CouldNotConnectToSomeServiceException)
   {
      //Do what you need to do
      throw;
   }
}



static void Main(string[] args)
{
    //sample 1
    if (IsServiceAlive())
    {
       //do something
    }

    //sample 2
    try
    {
       if (IsServiceAlive())
       {
          //do something
       }
    }
    catch (CouldNotConnectToSomeServiceException)
    {
       //handle here
    }

    //sample 3
    try
    {
       IsServiceAlive();
       //work
    }
    catch (CouldNotConnectToSomeServiceException)
    {
       //handle here
    }
}

您可以在上面看到，如果上下文只是一个二进制测试，则捕获示例 3 中的 CouldNotConnectToSomeServiceException 不一定会产生更好的可读性.但是，两者都有效.但真的有必要吗?如果您无法连接，您的程序是否已停止运行?它到底有多重要?这些都是您需要考虑的因素.很难说，因为我们无法访问您的所有代码.

You can see above, that catching the CouldNotConnectToSomeServiceException in sample 3 doesn't necessarily yield any better readability if the context is simply a binary test. However, both work. But is it really necessary? Is your program hosed if you can't connect? How critical is it really? These are all factors you will need to take in to account. It's hard to tell since we don't have access to all of your code.

让我们来看看其他一些最有可能导致问题的选项.

Let's take a look at some other options that most likely lead to problems.

//how will the code look when you have to do 50 string comparisons?  Not pretty or scalable.
public class ServiceConnectionStatus
{
     public string Description { get; set; }
}

和

//how will your code look after adding 50 more of these?
public enum ServiceConnectionStatus
{
   Success,
   Failure,
   LightningStormAtDataCenter,
   UniverseExploded
}