【问题标题】:Determining if PostgreSQL SQL exception is user error or system error判断PostgreSQL SQL异常是用户错误还是系统错误
【发布时间】:2011-02-21 15:25:03
【问题描述】:

我正在实现一个由 PostgreSQL 支持的 RESTful Web 服务。当 PostgreSQL 抛出 SQLException 时,HTTP 响应状态应该是 400 Bad Request 如果错误是某个值的输入字符串太长,或 500 Internal Server Error 如果磁盘崩溃。

对于人类来说,从异常中的消息中可以明显看出。但是有什么方法(现在他从 Jeopardy 回来后不租用 Watson)我的程序可以查看 SQLException 并猜测问题是用户错误还是系统错误?

我对 SQL 了解不多。我注意到 SQLState 是一个五个字符的字符串,前两个字符是“类代码”。

这是我目前的猜测:

Class 00:成功完成,没有抛出异常。

01 级:警告。在这种情况下会抛出 SQLException 吗?如果是这样,结果应该是 400 Bad Request。

Class 02:No Data(没有返回结果时的正常结果?)

类 03:SQL 语句尚未完成:可能是编程错误,而不是最终用户错误,因此是 500 Internal Server Error

Class 08: Connection Exception: 显然是 500 Internal Server Error

类 09 - 21:可能 500 内部服务器错误

第 22 类:数据异常。我正在处理的具体示例引发“22001 错误:类型字符变化(250)的值太长”。这应该作为 400 Bad Request 返回。 (在执行 SQL 语句之前对“名称”字段进行长度验证,但实际存储的值是完整路径名,即附加到其他内容的名称。)对于其他 22 类错误,我可能会返回 400 Bad Request ,尽管其中许多可能源于编程错误。

其他类看起来像 500 Internal Server Error 通常是更正确的状态。

【问题讨论】:

  • 什么是用户错误?。什么时候用户是非法的?通常不允许用户使数据库服务器崩溃。我怀疑大多数人会认为这些错误陈述中的任何一个都是可以理解的。似乎更好的方法是对常见的 oopsies 进行更多的测试和预期。

标签: sql postgresql sqlexception


【解决方案1】:

您可以考虑验证请求并仅在它们有效时将它们转发给 DB,DB 应该成功处理它们。在这种情况下,postgresql 返回的所有错误都可以认为是内部服务器错误。

【讨论】:

  • 一般来说这是一个好主意,我们尝试这样做,但是这个问题是由验证代码与 PostgreSQL 实际所做的不匹配的情况提示的。单元测试人员编写了一个预期 400 Bad Request 的测试并得到 500 Internal Server Error。但最终,未正确验证名称长度是一个编程错误,因此,矛盾的是,500 Internal Server Error 是正确的。
【解决方案2】:

手册是一个好的开始:Appendix A. PostgreSQL Error Codes

【讨论】:

  • 是的,这就是我在问题中获得信息的地方。一个好的开始,但只是一个开始。
猜你喜欢
  • 2011-02-28
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-02-04
  • 2011-05-17
  • 1970-01-01
  • 2016-05-10
  • 1970-01-01
相关资源
最近更新 更多