这是一个足够好的系统错误 - 用户友好 - 错误翻译器吗?

时间:2009-06-18 08:26:23

标签: design-patterns exception

这就是我翻译抛出错误的方法:

        catch (NpgsqlException ex)
        {
            if (tx != null) tx.Rollback();

            if (ex.Message.Contains("foreign key constraint"))
                throw new Exception("Cannot delete this, this record is already referenced on other record(s)");
            else
                throw new Exception(ex.Message, ex.InnerException);
        }

Npgsql样本约束错误:

  

错误:23503:在表格上更新或删除   “颜色”违反了外键   约束“fk_order_detail__color”on   表“order_detail”

4 个答案:

答案 0 :(得分:4)

您从异常中删除信息而不记录它。

我认为这是一个糟糕的电话 记录消息以便能够处理它,也不应该发生此错误。

重构,以免再次发生这种情况。

答案 1 :(得分:2)

您应该以这种方式编写问题,这样就不会导致SQL错误。

或者,如果您知道发生错误的具体原因,只需在接口中将其显示为消息,而不是错误。即“你应该删除删除这个对象之间的依赖关系”而不是“内部错误:无论什么”。

错误是出乎意料的;您的约束错误不是。

答案 2 :(得分:2)

如果您想更具体地处理某些错误,那么理想情况下您会创建一个ColorAlreadyUsedException class并抛出它。想一想caller如何区分这两种情况:是否需要检查消息?

仍然包含原始异常作为内部异常。

答案 3 :(得分:1)

在我已经有错误代码时,依赖于消息文本在我看来相当片状。虽然其他答案所概述的模式存在其他一些问题,但至少我会搜索“23503”而不是“外键约束”。否则,如果用户安装的数据库位于不同的文化中,或者服务器的更新版本更改了消息文本,会发生什么?


实际上查看一些online documentation您正在使用的异常类看起来甚至有一个Code属性,这比消息属性更快,更可靠。


最后的想法......

我同意Van的观点,当约束被破坏时你应该抛出一个更具体的异常,但是当错误是其他的时候你也不应该抛出一个基本的异常。首先,抛出基本异常类绝不是一个好习惯,因为它不会给客户端代码提供任何关于错误是什么的容易测试的信息。其次,您丢失了大量信息,NpgsqlException实现的所有额外属性以及堆栈跟踪。我用以下的东西代替投掷:

if (ex.Message.Contains("foreign key constraint"))
    throw new ConstraintException("Cannot delete this, this record is already referenced on other record(s)");
else
     throw;

基本上如果你不打算用异常做任何有效的事情,那么不要碰它,你永远不知道调用堆栈备份的信息代码是什么。