Question

所以我正在设计 Web服务当然;我需要此服务来自动写入数据库。这很直接;但显然 Sql 有不好玩的倾向。

在进行故障排除时，这几乎造成了一场噩梦，更不用说通过 Web服务，这将使调试成为一场噩梦。

所以我检查了互联网，偶然发现了一篇关于Stack Overflow的文章，该文章谈到了一个基本上有大量列表的 SqlHelper类：

public static bool IsDuplicateId(SqlException sex)
{
    return (sex.Number == 2601);
}

因此，您必须调用所有这些方法，因此实现会很繁琐。但是，有人回答：

switch (e.Number)
    case 2601:
         // Do Something
         break;
    default:
        throw;

所以我想为什么不创建 Class 来处理大多数这些可能的错误。考虑到这个特定的实现：

public class SqlExceptionHelper
{
    public SqlExceptionHelper(SqlException sqlException)
    {
        // Do Nothing.
    }

    public static string GetSqlDescription(SqlException sqlException)
    {
        switch (sqlException.Number)
        {
             case 21:
                 return "Fatal Error Occurred: Error Code 21.";
             case 53:
                 return "Error in Establishing a Database Connection: 53.";
             default
                 return ("Unexpected Error: " + sqlException.Message.ToString());
         }
     }
}

所以我的思维过程是我有一个 Class ，可以重用来检测一些常见的错误;在其他课程中我只是using SomeNamespace.ExceptionHelpers;我可以实现类似的东西：

public class SiteHandler : ISiteHandler
{
     public string InsertDataToDatabase(Handler siteInfo)
     {
          try
          {
              // Open Database Connection, Run Commands, Some additional Checks.
          }
          catch(SqlException exception)
          {
             SqlExceptionHelper errorCompare = new SqlExceptionHelper(exception);
             return errorCompare.ToString();
          }
     }
}

所以基本上它应该处理所有那些可爱的异常;但我开始思考哪个不好。 将此类例外作为退货回报？这本身可能不好吗？或者这是否真的是处理此类Exception捕获服务的最佳方式？

所以我的问题归结为：

       Is this the best way to handle error catching through a Service?

感谢您的帮助。

Answer 1

理想情况下，Web服务应返回相关的HTTP状态代码，而不是异常。这些通常是200（对于OK），400（对于用户可以自行修复的错误）或500（对于服务器错误 - 这些也可以自动重试）。

根据您返回的数据库错误，您可以将其转换为相应的HTTP状态代码。如果您认为错误代码对用户有帮助，则可以将其设置为异常消息。

捕获数据库异常

1 个答案: