PL SQL - 返回 SQLCODE 作为 OUT 参数是否被接受？答案

【问题标题】：PL SQL - Return SQLCODE as OUT parameter is accepted?PL SQL - 返回 SQLCODE 作为 OUT 参数是否被接受？
【发布时间】：2010-12-28 18:26:19
【问题描述】：

我有一个返回 OUT 参数的过程。

procedure foo (in_v IN INTEGER, out_v OUT integer)
BEGIN
...
EXCEPTION
  WHEN OTHERS THEN
    --sh*t happend
    out_v := SQLCODE;
END

如果一切正常，该参数将为 0，如果发生了不愉快的事情，该参数将为 0。

现在，如果 sh*t 一路发生，就会抛出异常。

可以将 SQLCODE 值赋给 OUT 参数吗？或者这是考虑到代码异味，我会被编程社区开除？

提前致谢。

【问题讨论】：

【解决方案1】：

如果没有对错误进行额外处理，我可能会建议不要这样做。这种方法只是让每个调用者都必须检查 out 参数的值。如果调用者忘记了它，一个严重的问题一开始可能会被忽视，并在其他地方造成难以调试的问题。

如果您根本不在这里捕获 OTHERS，则确保调用者必须显式捕获它，这样更简洁且更易于调试。

【讨论】：

【解决方案2】：

我想，它是否可以取决于你想用它实现什么。您要解决什么问题，或者您要满足什么要求？

通常的错误行为是优雅地处理您期望在正常运行期间可能发生的错误，并允许那些您不希望出现的错误，所以这看起来确实很奇怪。

【讨论】：

【解决方案3】：

没关系，但我不推荐它。通过这样做，您将强制调用代码进行非标准错误处理。如果您是唯一一个调用该代码的人并且您记得检查错误代码，这很好。但是，如果您在一个有多个程序员的大型系统中进行编码，我认为您应该善待您的其他程序员，并遵循该语言支持的标准异常处理方式。

如果您确实决定走那条路，也将 SQLERRM 传回，因为没有错误文本，您只有错误代码可以通过。经过多年为第三方软件中的数百个应用程序错误捕获“-20001”之后，SQLERRM 通常很重要。

【讨论】：

【解决方案4】：

由于多种原因，这种编码风格不是一个好主意。

首先，混合错误和异常是不好的做法，混合返回值和异常是更糟糕的做法。异常旨在跟踪异常情况 - 正常编程完全出乎意料的事情，例如内存不足问题、转换问题等，您通常不想在每个调用站点编写处理程序，但需要在某种程度上处理。

编码风格的第二个令人担忧的方面是，当遇到异常时，您的代码实际上是在向调用者发出信号，表明发生了不好的事情，但会很高兴地丢弃除 SQLCODE 之外的所有异常信息。

【讨论】：