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

Question

我有一个返回 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 参数吗？或者这是考虑到代码异味，我会被编程社区开除？

提前致谢。

score 11 · Accepted Answer

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

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

score 4 · Accepted Answer

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

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

score 2 · Accepted Answer

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

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

score 0 · Accepted Answer

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

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

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

4 回答 4