PL SQL - 返回 SQLCODE 作为 OUT 参数是否被接受？
我有一个返回 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 如果发生了不好的事情。
现在，如果一路上发生了糟糕的事情，就会抛出异常。
可以将 SQLCODE 值赋给 OUT 参数吗？或者这被认为是一种代码味道，我将被逐出编程社区？
提前致谢。
I have a procedure that returns an OUT parameter.
procedure foo (in_v IN INTEGER, out_v OUT integer)
BEGIN
...
EXCEPTION
WHEN OTHERS THEN
--sh*t happend
out_v := SQLCODE;
END
That parameter will be 0 if everything goes OK, and <> 0 if something ugly happened.
Now, if sh*t happens along the way, an exception will be thrown.
Is it ok to assing the SQLCODE value to the OUT parameter ? Or is this consideres a code smell, and I will be expelled from the programming community ?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果没有对错误进行额外的处理，我可能会建议不要这样做。这种方法只是让每个调用者都必须检查 out 参数的值。如果调用者忘记了它，一个严重的问题可能一开始不会被注意到，并在其他地方造成难以调试的问题。
如果您只是不在这里捕获其他内容，则可以确保调用者必须显式捕获它，这更干净且更易于调试。
If there is no additional handling of the error, I would probably advise against it. This approach just makes it necessary for each caller to examine the value of the out parameter anyway. And if the caller forgets it, a serious problem may pass unnoticed at first and create a hard to debug problem elsewhere.
If you simply don't catch OTHERS here, you ensure that the caller has to explicitly catch it, which is a lot cleaner an easier to debug.
我想，它是否可以取决于你想用它实现什么。您想解决什么问题，或者您想满足什么要求？
错误的常见行为是优雅地处理您期望在正常运行期间可能发生的错误，并允许那些您不希望出现的错误，因此这看起来确实很奇怪。
Whether it's OK or not depends on what you're trying to achieve with it, I suppose. What problem are you trying to solve, or what requirement are you trying to meet?
the usual behaviour with errors is to gracefully handle the ones that you expect might happen during normal functioning and to allow those that you do not expect to be raised, so this does look odd.
没关系，但我不推荐它。通过这样做，您将强制调用代码进行非标准错误处理。如果您是唯一调用该代码的人并且您记得检查错误代码，那么这很好。但是，如果您在具有多个程序员的大型系统中进行编码，我认为您应该善待其他程序员并遵循该语言支持的异常处理的标准方法。
如果您确实决定走这条路线，也请传回 SQLERRM，因为没有错误文本，您只有错误代码可供参考。经过多年捕获第 3 方软件中数百个应用程序错误的“-20001”之后，SQLERRM 通常很重要。
Its ok, but I don't recommend it. By doing it this way you're forcing the calling code to do non-standard error handling. This is fine if you are the only person ever calling the code and you remember to check the error code. However, if you're coding in a large system with multiple programmers I think you should be kind to your fellow programmers and follow the standard way of exception handling supported by the language.
If you do decide to go down that route, also pass back SQLERRM as without the error text you only have the error code to go by. After years of catching "-20001" for the hundreds of application errors in 3rd party software the SQLERRM is often important.
由于多种原因，这种编码风格并不是一个好主意。
首先，混合错误和异常是不好的做法，混合返回值和异常更糟糕。异常旨在跟踪异常情况 - 正常编程完全意想不到的事情，例如内存不足问题、转换问题等，您通常不希望在每个调用站点编写处理程序，但需要在某种程度上进行处理。
编码风格的第二个令人担忧的方面是，您的代码实际上是在表示，当遇到异常时，代码将向其调用者发出信号，表明发生了一些不好的事情，但会很高兴地丢弃除 SQLCODE 之外的所有异常信息。
This coding style is not a good idea for a number of reasons.
First, it is bad practice to mix errors and exceptions, even worse practice to mix return values and exceptions. Exceptions are meant to track exceptional situations - things completely unexpected by normal programming such as out of memory issues, conversion problems and so on that you normally would not want to write handlers at every call site for but need to deal with at some level.
The second worrying aspect of the coding style is that your code is effectively saying when an exception is encountered, the code will signal to its caller that something bad has happened but will happily throw away ALL exception information except for the SQLCODE.