我们总是在PLSQL过程中看到这种结构,但是如果我使用许多开始end,有什么区别呢?有些人喜欢写许多嵌套的BEGIN,end,而有些过程只写一对BEGIN,为什么?这就产生了另一个问题,EXCEPTION必须在END之前结束吗?如果你想在一个过程中定义多个EXCETPION,你必须定义多个BEGIN,END。
BEGIN
...
EXCEPTION WHEN .. THEN
...
END
BEGIN
begin
...
end;
begin
...
end;
...
EXCEPTION WHEN .. THEN
...
END
我想知道在许多开始结束写代码有什么好处吗?我将不胜感激,如果你能解释给我听,谢谢
2条答案
按热度按时间gg0vcinb1#
这取决于程序做什么;有时是简单的
BEGIN-EXCEPTION-END
,有时是更多的BEGIN-EXCEPTION-END
(包含在“主”BEGIN-END
中)。多个块的示例:
如果只是一个BEGIN-END,我将无法处理两个失败的
SELECT
,因为我不知道 * 哪一个 * 失败了:嵌套
BEGIN-EXCEPTION-END
的另一种用法是在循环中;如果代码(在循环中)失败,则循环停止。如果您处理错误,则让其他循环继续。当您遇到失败的面向集合的查询,并且您不知道是什么/谁造成的问题时,这一点特别有用。在循环中,您可以 * 隔离 * 它(啊哈!好了,现在我知道要修复什么了!),然后重新运行原始查询。例如:没有它:
fkaflof62#
完整语法为
declare
和exception
是可选的。这些关键字本身没有任何作用,因此
是一回事
像这样的子块只有在您只想为一个特定部分执行
declare
操作时才有用,例如或者,如果您希望某个特定步骤使用
exception
(这是跟踪错误详细信息的好方法-初学者的错误是编写大量杂乱无章的过程,但底部只有一个异常处理程序,这样就无法捕获足够有用的错误信息,例如确切的步骤失败或无法处理哪些参数值)。或者当然两者都有。
如果一个子块变得很复杂,有很多局部变量和代码行等,那么你可以考虑将它重构为一个单独的过程,例如:
其中
launch_rocket_into_space()
是调用how_about_we_give_this_a_try()
并处理零分频错误的过程。