we started using madexcept instead of excmagic our exception handler. working on 64 bit build of our app , therefore eliminate, if possible, uses of asm code.
excmagic had procedure create access violation testing purposes.
procedure createaccessviolation begin asm mov eax,11111111h mov ebx,22222222h mov ecx,33333333h mov edx,44444444h inc dword ptr [eax] end; end; is there advantage using code instead of writing
raise eaccessviolation.create('just testing...'); there must reason excmagic developers used that.
thanks!
exceptions, @ os level, not objects. they're numeric values might carry additional context data. when attempt read or write invalid address, exception code exception_access_violation context giving attempted operation , address, when use raise reserved word, exception code cdelphiexception connect giving delphi object reference. (did know can throw any object, not descendants of exception?)
in delphi parlance, os-level exception referred run-time error.
there's code in sysutils unit transform access-violation run-time error, created assembly code, eaccessviolation delphi exception. makes easy catch delphi's try-except syntax.
if there's non-delphi code on call stack (or maybe delphi code isn't using sysutils), won't recognize cdelphiexception exception code, , if does, might not able differentiate 1 delphi object type another. exception_access_violation, on other hand, known throughout windows code.
if want test behavior access violation, it's best there actual violation of access. that's assembly code attempts do. (whether succeeds @ separate issue.) if want test catching of delphi objects, throw whatever objects want, including instances of eaccessviolation.
Comments
Post a Comment