|
Your question isn't clear. What type of report is it? SQL Server Reporting? Business Objects? Crystal? We can't see your monitor, so we have no idea.
|
|
|
|
|
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
{
try
{
...
try
{
...
Abort;
...
}
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
{
try
{
...
try
{
...
throw new MyCustomException();
...
}
catch (MyExeption1 ex)
{
}
}
catch (MyExeption2 ex)
{
}
}
catch (MyCustomException ex)
{
}
finally
{
}
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'.
|
|
|
|
|
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.
|
|
|
|
|
Take a simple example from here[^]
The following example, try remove "new" from B.Yell, it makes no difference (except Compiler will bitch about it).
Let me know if I am mistaken!
<br />
class Program<br />
{<br />
static void Main(string[] args)<br />
{<br />
try<br />
{<br />
A ref1 = new A(); <br />
A ref2 = new B();<br />
B ref3 = new B();<br />
<br />
ref1.Y(); <-- A.Yell<br />
ref2.Y(); <-- B.Yell<br />
ref3.Y(); <-- Always B.Yell, regardless whether you decorated Yell() with "new" or not! (This makes the keyword useless)<br />
}<br />
catch (Exception Ex)<br />
{<br />
Console.WriteLine("Main.Exception - " + Ex.ToString());<br />
}<br />
<br />
return;<br />
}<br />
<br />
class A<br />
{<br />
public void Yell()<br />
{<br />
Console.WriteLine("A.Yell");<br />
}<br />
}<br />
<br />
class B : A<br />
{<br />
public new void Yell()<br />
{<br />
Console.WriteLine("B.Yell");<br />
}<br />
}<br />
}<br />
dev
modified 31-Jan-13 0:26am.
|
|
|
|
|
Why would you expect A.Yell to be called when you have a reference to B?
...or did you mean to place your "Always B.Yell..." comment at ref2?
Kind Regards,
Keld Ølykke
|
|
|
|
|
Keld Ølykke wrote: Why would you expect A.Yell to be called when you have a reference to B?
Then what good is decorating the method B.Yell with "new" keyword? In the example, it does absolutely nothing. (i.e. remove it, you still have same result)
dev
|
|
|
|
|
If you mean to call a base class method by inheritance there is 2 options:
1) inherited class does not override or new a base class method => B.Yell() will call A.Yell() in all cases
2) inherited class does override or new a base class method => B.Yell() has the full responsibility for calling base.Yell()
You're example is not supposed to call base method, since you are missing a base.Yell() call in B - and it has nothing to do with the new keyword.
Kind Regards,
Keld Ølykke
|
|
|
|
|
i know how to call the base class method - i am asking if "new" is useless, that its own relevance is to silence compiler warning.
Read this.[^]
dev
|
|
|
|
|
Okay. I was in doubt about what you wanted to happen in your example.
I have a problem with your word useless. I think you refer to compiled code not changing behavior or something similar.
If so, I disagree with that opinion. In C# great efforts has been made to avoid that the programmer by accident does something he didn't mean to. One way that this is done, is by the introduction of more keywords e.g. virtual+override or new. This attitude from the language design team makes C# my favorite programming language.
In short, no, I don't find it useless, and, yes, it seems to "just" hide a compiler warning 
Kind Regards,
Keld Ølykke
|
|
|
|
|
Thank you Keld, I was just looking for some sort of confirmation.
dev
|
|
|
|
|
I am pretty sure that the sole purpose of the new keyword in this context, is to hide the warning and has no other effect.
And to back it up :
When used as a modifier, the new keyword explicitly hides a member inherited from a base class. When you hide an inherited member, the derived version of the member replaces the base-class version. Although you can hide members without the use of the new modifier, the result is a warning. If you use new to explicitly hide a member, it suppresses this warning and documents the fact that the derived version is intended as a replacement.
2A
modified 31-Jan-13 3:31am.
|
|
|
|
|
Great! Thanks Markovl!
dev
|
|
|
|
|
The main intent of the new keyword in C# in this context is to let programmers and reviews know that this method is not an override and 'shadows' the base class method. This is specially targeted towards C++ programmers who migrated to C#. Remember, C++ does not have the override keyword.
Thew new keyword also enables you to 'shadow' or 'redefine' a virtual method in a derived class. IMO, this was not possible in C++. Correct me if I'm wrong.
modified 31-Jan-13 7:18am.
|
|
|
|
|
The new keyword does not make a difference in the case you are looking at.
A bigger difference is made in the line A ref2 = new B();
If you remove new and use the override keyword, your output will be
A.Yell<br />
B.Yell
This article[^] explains the difference quite clearly.
|
|
|
|
|
Abhinav S wrote: A bigger difference is made in the line A ref2 = new B();
You are wrong, I suggest you try it yourself. As pointed out by Markovl and myself this post, removing "new" makes no difference besides silencing compiler warning.
Also, check out MSDN:[^]
When used as a modifier, the new keyword explicitly hides a member inherited from a base class. When you hide an inherited member, the derived version of the member replaces the base-class version. Although you can hide members without the use of the new modifier, the result is a warning. If you use new to explicitly hide a member, it suppresses this warning and documents the fact that the derived version is intended as a replacement.
This is just another useless facility only relevant in enterprise interviews.
dev
|
|
|
|
|
|
i didn't miss anything Abhinav,
(a) I wasn't asking about 'override' or polymorphism
(b) *new* in context of method hiding really does nothing except to silence compiler warning
dev
|
|
|
|
|
Hi, is there any fool proof way to catch unhandled thread exception, whether it's a ThreadAbortException (caused by Thread.Abort from "Main" or UI thread) or a DivisionByZeroException (happenning within the thread function)?
I know the following won't catch it:
<br />
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(UnhandledExHandler);<br />
And I don't think all developers will implement try-catch-finally on thread functions. How do you handle this?
I know for WPF app, in App.xaml you can define general handler for unhandled exceptions (But this will NOT catch Thread exceptions). For example, the following will NOT work:
<br />
private void Application_DispatcherUnhandledException_1(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)<br />
{<br />
string Message = "Unhandled exception: " + e.Exception.ToString();<br />
MessageBox.Show(Message);<br />
return;<br />
}<br />
dev
|
|
|
|
|
Well, I allways have a try/catch in my threads. Usualy I catch TreadAbortException and other "most excpected" exceptions and at the end I allways catch general exceptions and log them.
In debug mode I tend to insert a Debug.Assert(false) in the general exception handler, to see if I forgot an "expected" exception.
In the release they are only logged.
Some people say, that you shold not catch general exceptions, but the software I'm used to work on has to run 24/7 and most of the time without a user in front of it. So it has te recover itself after the occurence of any kind of error.
I don't know how others manage it, but I don't like software which crashes totally, only showing a messagebox with an error and then say good-bye without any chance of saving data or anything else.
Andy
|
|
|
|
|
In WinForms, there is no way to prevent the termination of an app caused by an unhandled thread exception. AppDomain.UnhandledException will handle it, but will not prevent the app termination. The best you can do in this event handler is to save your data and gracefully exit the program.
I always have a top level try catch block in the method directly executed in a thread. This will handle all exceptions thrown from any where down in the call stack.
|
|
|
|
|
devvvy wrote: Hi, is there any fool proof way to catch unhandled thread exception,
No because for starters the StackOverflowException cannot be caught.
But for the rest, always, always, put a try/catch at the root level of where you start the thread from.
|
|
|
|
|
Thought I said ThreadAbortException...
dev
|
|
|
|
|
devvvy wrote: Thought I said ThreadAbortException...
You did. You also asked if you could catch all exceptions. The one I posted cannot be caught.
The ThreadAbortException (not what I mentioned) is special both it what it does to a thread and what it does on exit from the catch block (excluding special handling.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
