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，并且＆lt;＆gt;如果发生了丑陋的事情，那就是0。

现在，如果在此过程中发生了sh * t，则会抛出异常。

将SQLCODE值分配给OUT参数是否可以？或者这是一个代码味道，我将被驱逐出编程社区？

提前致谢。

Answer 1

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

如果你根本没有在这里找到OTHERS，你可以确保调用者必须明确地捕获它，这样更容易调试。

Answer 2

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

错误的常见行为是优雅地处理您在正常运行期间可能发生的行为并允许那些您不期望被引发的行为，因此这看起来很奇怪。

Answer 3

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

如果你决定沿着那条路走下去，也要传回SQLERRM而没有错误文本，你只有错误代码。对于第三方软件中数百个应用程序错误捕获“-20001”多年后，SQLERRM通常很重要。

Answer 4

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

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

编码风格的第二个令人担忧的方面是你的代码有效地说当遇到异常时，代码会向其调用者发出信号，告知发生了一些不好的事情，但是除了SQLCODE之外，它会很乐意抛弃所有异常信息。 / p>