|
|
Hello,
I've read tons of materials all over codeproject and google about last chance exception handling. Most of the suggested solutions include subscribing to Application.ThreadException and AppDomain.CurrentDomain.UnhandledException to handle both exceptions in current and different thread context. Under debug configuration the exceptions are caught as expected, but under release the CLR unhandled exception dialog is shown and the handler is not invoked.
What is the proper way of handling ALL exceptions (as to provide logging before exit) in WinForms application?
modified on Friday, July 22, 2011 10:46 AM
|
|
|
|
|
I've attached a handler to AppDomain.CurrentDomain.UnhandledException with good results. You need to do it before you call Application.Run, though.
|
|
|
|
|
It is attached at the beginning of Main() (much before Application.Run) as follows:
[STAThread]
static void Main()
{
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
...
}
Did you catch the exceptions under Release configuration?
|
|
|
|
|
Yes. I didn't even do the first call. It is only for exceptions in the UI thread, though ... I don't have a ThreadException handler (all threaded code is self-protected).
|
|
|
|
|
Hello coders
I want to know what will be the main features we have to use to increase application performance. Specially for data updations. There are many available but I want to know the best one.
Any help.
|
|
|
|
|
What kind of app, in witch context, made with witch technology??? Give as more details, in this way it is too generic!
|
|
|
|
|
This really is very generic. You may make use of profiler to see where the loop holes are and then fix them. Since you are speaking of data updations, here are few things to take care of:
1. Connections should be used wisely.
2. Proper indexing.
3. Efficient queries.
"The worst code you'll come across is code you wrote last year.", wizardzz[ ^]
|
|
|
|
|
Don't repost questions. You could simply have updated your other question to clarify it.
|
|
|
|
|
Calling the same method twice will definitely effect performance and response times
"You get that on the big jobs."
|
|
|
|
|
Database related? Reuse Connections, Commands, and Parameters as much as possible -- don't keep instantiating and disposing them.
|
|
|
|
|
I don't think that is quite right. Under the covers, .NET maintains a connection pool so it is best to open the connection, do the work and then close it.
Use using, create the connection, command and parameters. Do the work and get out of there.
"You get that on the big jobs."
|
|
|
|
|
Yes, open and close it, don't dispose of it.
RobCroll wrote: Use using, create the connection, command and parameters
Absolutely not.
|
|
|
|
|
There is not one answer because it depends on what your app is doing - having said that here are 3 things I have learnt from experience.
(1)If you do not need to refresh or send information to a form then don't - screen refreshes are expensive.
(2)If you can sleep a thread then do - looping though a thread waiting for something to happen is expensive.
(3)With reference to 2 above - make your application as event driven as you can so that you are never waiting for something to happen.
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
|
Hi,
We need frequent data updations in real time updating application like online treading and like these others. I will suggest you to go for dapfor .net grid which is capable in real-time data processing like real-time data updating, real-time data highlighting, real-time data sorting and real -time data filtering.
Cheers,
|
|
|
|
|
Over 52 MILLION Google results for ".net performance best practices"[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Hi,
I want to know, what are the major factors which effect our application performance, including all or any.
|
|
|
|
|
Badly written code. Lack of knowledge.
|
|
|
|
|
You forgot not enough homework
P
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
1. Bad design.
2. Bad programming.
3. Inefficient hardware.
"The worst code you'll come across is code you wrote last year.", wizardzz[ ^]
|
|
|
|
|
Poor architecture and rigid development environments.
Poor architecture speaks for itself. If the architect gets it wrong, no number of builders will fix the problem, the house is going to fall down.
Also rigid development environments mean developers are put in there place and not given the freedom to refractor the code.
An example I clearly remember was a situation where a number of methods were passing many parameters and requesting the same data multiple times. By encapsulating the parameters, the methods became a lot more maintainable and only had to do the work once. This is not something an architect is in a position to envisage.
Senior developers need the freedom to pull on the cowboy boots from time to time. They also need to keep an open mind and an open door to junior developers.
"You get that on the big jobs."
|
|
|
|
|
RobCroll wrote: pull on the cowboy boots
To squash bugs in the corners?
|
|
|
|
|
RobCroll wrote: An example I clearly remember was a situation where a number of methods were passing many parameters and requesting the same data multiple times. By encapsulating the parameters, the methods became a lot more maintainable and only had to do the work once. This is not something an architect is in a position to envisage.
And by doing only that by what percentage was the performance of the application reduced?
|
|
|
|
|
 It didn't reduce performance, it improved it. Didn't benchmark the change but it reduced requests to the database by approx 66%
"You get that on the big jobs."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
