|
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.)
|
|
|
|
|
I would expect some exceptions to be thrown within the threads and some thread related exceptions to be thrown back to the main thread; ThreadAbortException could be one of the later.
In the later case, I would expect the following code to catch all exception thrown within the main thread:
[STAThread]
[SuppressMessage("Microsoft.Usage", "CA1801")]
public static int Main(string[] args)
{
Program program = new Program();
do
{
try
{
program.Update();
Application.DoEvents();
}
catch (Exception exception)
{
if (program.Log.IsFatalEnabled)
{
program.Log.Fatal("Caught Unhandled Exception: " + exception);
}
break;
}
}
while (program.StateCurrent != EProgramState.Shutdown
&& program.ExitCode == EProgramError.NoError);
return (int)program.ExitCode;
}
If ThreadAbortException is thrown within the thread, I would look for a way to register my own thread main method and do similar wrapping in there.
Kind Regards,
Keld Ølykke
|
|
|
|
|
Hi,
I have two try blocks, two catches and one finally block.
I have logic written in the first try block. But if one of the conditions is hit, I want the program to go to finally block directly, since I am closing all connections here, and then exit program.
If I use Environment.Exit(); then it will end the program, and I would not have closed the connection to database that is open.
How can I force program to go to finally block wit hexecuting the remaining code?
|
|
|
|
|
if you exit the try block it would automatically pass through finally block no matter how it exits the try block i.e either through catch or through return statement.
have you tried to debug this. you may paste the code block if it still didnt work.
Jibesh V P
|
|
|
|
|
I am going to use a return. But this exits the whole program. So, within this condition, I am going to close the connection and have a return.
|
|
|
|
|
what makes the program to exit? is that how it has to work?
Quote: So, within this condition, I am going to close the connection and have a return
since you want to close the connection before the application exists thats the best place to do this reset.
Jibesh V P
|
|
|
|
|
If the database returns 0 rows, exit else continue.
|
|
|
|
|
Ok. did I answer your question? if not can you please share the code for the better understanding of your problem.
Jibesh V P
|
|
|
|
|
Yes, I think the general concensus is that, put try-catch-finally in all thread functions as coding practice.
dev
|
|
|
|
|
vanikanc wrote: If I use Environment.Exit(); then it will end the program, and I would not have closed the connection to database that is open.
It will not end the program, but terminate it.
Use Application.Terminate for a WinApp, and simply return from the Main method (the entry-point) if you're writing a Console App.
|
|
|
|
|
vanikanc wrote: two try blocks, two catches and one finally block
You'd have to show the code for us to understand how you have them arranged.
vanikanc wrote: closed the connection to database
You should be using a using statement as well -- it's similar to a try/finally.
vanikanc wrote: Environment.Exit();
Don't do that; just return.
|
|
|
|
|
vanikanc wrote: then it will end the program, and I would not have closed the connection to
database that is open.
When the program terminates the connection will be terminated as well.
And the only way you can terminate a database connection in C# anyways is if all of the following are true.
1. You have configured the connection pool to keep no idle connections.
2. There are no connections in use
3. You reset the pool.
Other than that just "closing" the connection does nothing more than return it to the connection pool.
|
|
|
|
|
Just return from the method. The finally block will execute and then your method will return.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
