delphi – 可以从引发异常的点恢复执行吗?

前端之家收集整理的这篇文章主要介绍了delphi – 可以从引发异常的点恢复执行吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
有一个例子说明了我的问题:
procedure Test;
begin
  try
    ShowMessage('1');
    raise EWarning.Create(12345,'Warning: something is happens!');
    ShowMessage('2');
  except
    on E: EWarning do
      if IWantToContinue(E.ErrorCode) then
        E.SkipThisWarning // shows '1' then '2'
      else
        E.StopExecution;  // shows '1'
  end;
end;

function IWantToContinue(const ErrorCode: Integer): Boolean;
begin
  //...
end;

我尝试使用这样的东西:

asm
  jmp ExceptAddr
end;

但它不会工作……

有任何想法吗?

谢谢.

解决方法

不,这是不可能的:

有两种例外:程序员使用raise命令引发的逻辑异常,以及cpu针对各种条件启动的外部异常:除零,堆栈溢出,访问冲突.对于第一种,逻辑异常,你无能为力,因为它们是应用程序“流”的一部分.你不能搞乱第三方代码的流程,你甚至不能搞乱你自己的代码流.

外部例外

当指令失败时,通常会因运行单个cpu指令而引发这些指令.在德尔福,这些作为EExternal后代提供.该列表包括访问冲突,除以零,特权指令和其他许多其他指令.从理论上讲,对于其中一些异常,可以删除异常的导致条件并重试单个cpu指令,允许原始代码继续,就好像没有发生错误一样.例如,通过在发生错误的地址实际映射RAM页面,可能会“修复”某些访问冲突.

Windows提供的SEH(结构化异常处理)机制中有一些规定用于处理此类可重试错误,Delphi正在使用SEH.不幸的是,Delphi没有公开所需的元素以使其易于访问,因此使用它们即使不是不可能也是非常困难的.尽管如此,对于特定类型的EExternal错误,聪明的Delphinians可能会尝试编写自定义SEH代码并使其工作正常.如果是这种情况,请提出一个新问题,提到您正在获取的特定类型的错误以及您要采取的删除错误条件的步骤:您将获得一些工作代码或定制解释为什么您的错误想法不会奏效.

通过使用raise引发的逻辑异常

大多数异常都属于这一类,因为大多数代码会在执行潜在危险的低级别操作之前检查它的输入.例如,在尝试访问TList中的无效索引时,将检查索引并在尝试访问请求的索引之前引发无效索引异常.如果没有检查,访问无效索引将返回无效数据或引发访问冲突.这两个条件都很难跟踪错误,因此无效索引异常是一件非常好的事情.为了这个问题,即使代码被允许访问无效索引,导致访问冲突,也不可能“修复”代码并继续,因为没有办法猜测正确的索引应该是什么.

换句话说,修复“逻辑”异常不起作用,不应该起作用,而且它非常危险.如果引发错误代码是您的,那么您可以简单地将其重组为不引发警告异常.如果那不是你的代码,那么继续异常就属于“疯狂危险”类别(更不用说它在技术上是不可能的).在查看已编写的代码时,请问自己:如果使用ShowMessage替换引发的Exeption,代码是否会正常运行?答案应该主要是“不,代码会失败”.对于非常罕见,非常错误的第三方代码,由于没有充分理由引发异常,您可能会要求在运行时修补代码以避免引发异常的特定帮助.

以下是一些第三方代码中的内容

function ThirdPartyCode(A,B: Integer): Integer;
begin
  if B = 0 then raise Exception.Create('Division by zero is not possible,you called ThirdPartyCode with B=0!');
  Result := A div B;
end;

很明显,在异常之后继续该代码不会允许东西“自我修复”.

第三方代码也可能如下所示:

procedure DoSomeStuff;
begin
  if SomeCondition then
    begin
      // do useful stuff
    end
  else
    raise Exception.Create('Ooops.');
end;

代码在哪里“继续”?很明显不是“做有用的东西”的一部分,除非代码是专门设计的.

当然,这些仅仅是表面上的简单例子.从技术角度来看,在你建议的异常之后“继续”比在跳转错误的地址要困难得多.方法调用使用堆栈空间来设置局部变量.在错误之后“回滚”过程中,该空间在前往异常处理程序的过程中被释放.最后执行了块,可能在需要时解除分配资源.跳回到原始地址将是非常错误的,因为调用代码不再具有它在堆栈上所期望的内容,它的局部变量不再是他们想要的.

如果是你的代码提出异常

您的代码很容易修复.使用这样的东西:

procedure Warning(const ErrorText:string);
begin
  if not UserWantsToContinue(ErrorText) then
    raise Exception.Create(ErrorText);
end;

// in your raising code,replace:
raise Exception.Create('Some Text');

// with:
Warning('Some Text');

猜你在找的Delphi相关文章