How to write c# version of Delphi's Abort procedure
-
Delphi has a precedure named "Abort".The following is picked up from Delphi help: Use Abort to escape from an execution path without reporting an error.Abort raises a special "silent exception" (EAbort), which operates like any other exception, but does not display an error message to the end user. Abort redirects execution to the end of the last try .. finally block.
EAbort = class(Exception);
procedure Abort;
function ReturnAddr: Pointer;
asm
MOV EAX,[EBP - 4]
end;
begin
raise EAbort.Create(SOperationAborted) at ReturnAddr;
end;I'm now going to .Net. I can not find any method Similar to the "Abort" procedure.Is it possible to to write c# version of Delphi's "Abort" procedure like this?
try //application level try .. finally block
{
try
{
...
try //Current level try .. finally block
{
...
// Throw a SilentException that will only catched by application level try .. finally block
// and redirects execution to the end of application level try .. finally block
Abort; //How to??????????????????????????
...
}
catch
{
}
}
catch
{
}
}
catch ()
{
}
finally
{
}
...Can anyone help me? Any suggestion wil be appropriate. Thanks a lot. .
Forgive my poor English
-
Delphi has a precedure named "Abort".The following is picked up from Delphi help: Use Abort to escape from an execution path without reporting an error.Abort raises a special "silent exception" (EAbort), which operates like any other exception, but does not display an error message to the end user. Abort redirects execution to the end of the last try .. finally block.
EAbort = class(Exception);
procedure Abort;
function ReturnAddr: Pointer;
asm
MOV EAX,[EBP - 4]
end;
begin
raise EAbort.Create(SOperationAborted) at ReturnAddr;
end;I'm now going to .Net. I can not find any method Similar to the "Abort" procedure.Is it possible to to write c# version of Delphi's "Abort" procedure like this?
try //application level try .. finally block
{
try
{
...
try //Current level try .. finally block
{
...
// Throw a SilentException that will only catched by application level try .. finally block
// and redirects execution to the end of application level try .. finally block
Abort; //How to??????????????????????????
...
}
catch
{
}
}
catch
{
}
}
catch ()
{
}
finally
{
}
...Can anyone help me? Any suggestion wil be appropriate. Thanks a lot. .
Forgive my poor English
-
Delphi has a precedure named "Abort".The following is picked up from Delphi help: Use Abort to escape from an execution path without reporting an error.Abort raises a special "silent exception" (EAbort), which operates like any other exception, but does not display an error message to the end user. Abort redirects execution to the end of the last try .. finally block.
EAbort = class(Exception);
procedure Abort;
function ReturnAddr: Pointer;
asm
MOV EAX,[EBP - 4]
end;
begin
raise EAbort.Create(SOperationAborted) at ReturnAddr;
end;I'm now going to .Net. I can not find any method Similar to the "Abort" procedure.Is it possible to to write c# version of Delphi's "Abort" procedure like this?
try //application level try .. finally block
{
try
{
...
try //Current level try .. finally block
{
...
// Throw a SilentException that will only catched by application level try .. finally block
// and redirects execution to the end of application level try .. finally block
Abort; //How to??????????????????????????
...
}
catch
{
}
}
catch
{
}
}
catch ()
{
}
finally
{
}
...Can anyone help me? Any suggestion wil be appropriate. Thanks a lot. .
Forgive my poor English
Assuming that you wish to exit out of all try blocks and continue execution from the line next to the last finally block, you can try this:
try //application level try .. finally block
{
try
{
...
try //Current level try .. finally block
{
...
// Throw a SilentException that will only catched by application level try .. finally block
// and redirects execution to the end of application level try .. finally block
throw new MyCustomException();
...
}
catch (MyExeption1 ex)
{
}
}
catch (MyExeption2 ex)
{
}
}
catch (MyCustomException ex)
{
}
finally
{
}//Execution will continue from here
What this code basically does is exploit the behavior of try catch blocks. When an exception is not handled by the inner catch block, the next outer catch block will try to handle it and so on. Note that all finally blocks will be executed anyway, if you do not wish this to happen, you can control the code flow with flag variables. Points to keep in mind: 1. Don't handle any super-class of the exceptions raised in the respective catch blocks. 2. Don't handle System.Exception in the inner catch blocks. A better way would be to re-design your code and make it modular with multiple outer try catch blocks and avoid 'block jumps'.
-
Delphi has a precedure named "Abort".The following is picked up from Delphi help: Use Abort to escape from an execution path without reporting an error.Abort raises a special "silent exception" (EAbort), which operates like any other exception, but does not display an error message to the end user. Abort redirects execution to the end of the last try .. finally block.
EAbort = class(Exception);
procedure Abort;
function ReturnAddr: Pointer;
asm
MOV EAX,[EBP - 4]
end;
begin
raise EAbort.Create(SOperationAborted) at ReturnAddr;
end;I'm now going to .Net. I can not find any method Similar to the "Abort" procedure.Is it possible to to write c# version of Delphi's "Abort" procedure like this?
try //application level try .. finally block
{
try
{
...
try //Current level try .. finally block
{
...
// Throw a SilentException that will only catched by application level try .. finally block
// and redirects execution to the end of application level try .. finally block
Abort; //How to??????????????????????????
...
}
catch
{
}
}
catch
{
}
}
catch ()
{
}
finally
{
}
...Can anyone help me? Any suggestion wil be appropriate. Thanks a lot. .
Forgive my poor English
Xiaoming Qian wrote:
Can anyone help me? Any suggestion wil be appropriate.
Don't do that. Such an idiom should almost never be used. I only say "almost" because I don't like absolutes and in fact I don't know of any case that would suggest the use. Given that it should never be used if someone comes across a case where it seems like a good idea then the first step should be to evaluate the architecture/design/implementation to look for errors that led to thinking it would be a good idea in the first place.