Hi , 
Thank for reply of Ayyappan Nair and Mark , it's very helpful ! ;> 

And further,Ayyappan Nair ,I see my question in your code , could you
explain to me when could I open a connection . Can I open only one
connection before start my main form (I really want to do that !) and
close it when my app exit. I ask this because in all book I read , they
always recommend to open a connection on a function and close it when
done , but I think it spends many time to open/close and open/close
again and again. On other hand , I can open only a connection and hold
it during my app run - what's the disadvantage of this way ( I was read
about connection pooling but it isn�t enough to me !)      

 
Th�i Tr� H�ng
Software Solution Center 
HPT Vietnam Co Ltd
tel : (084)  8.458518 - Ext : 327
mobile : 0908391763
 
 



-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Gibson, M
(Mark)
Sent: Friday, March 28, 2003 5:46 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Which way is the better way to trap all
unexpected exception !


You should also be aware that setting the UnhandledExceptionEventHandler
delegate will only work for the default AppDomain.  If you are creating
your own AppDomains you will have to come up with an alternative
approach.

Mark

-----Original Message-----
From: Ayyappan Nair [mailto:[EMAIL PROTECTED]
Sent: 27 March 2003 23:33
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Which way is the better way to trap all
unexpected exception !


Hi,

Any Unhandled Exception will generate an UnhandledException Event and
this can be trapped by the UnhandledExceptionEventHandler delegate. The
method associated with the delegate will be executed every time an
Unhandled Exception occurs. Inside this method you can do any processing
you want like your BugTracking.LogException(ex); and maybe inform the
user that a fatal error occurred and then exit the application. 

Whether the application should terminate or user should be allowed to
continue after an exception, depends on the kind of Exception being
thrown. I think you should have separate catch blocks for the kind of
exceptions that can be identified as not fatal and allow the user to
continue with the application. The catch filter should be based on the
type of exceptions likely in the try block. Regarding
Application.Exit(), this will terminate only the current thread. So if
it's called in any other thread other than the Main thread, only that
thread will terminate, but the main thread will continue to execute. You
might want to use Environment.Exit() to terminate the application caused
by a fatal error from any thread.

[STAThread]
static void Main() 
{ 
        AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(UnhandledHandler);  
        try
        {
                string strConnect="Provider=Microsoft.Jet.OLEDB.4.0;Data
                        Source=db.mdb;Persist            Security
Info=False;";
        OleDbConnection conn=new OleDbConnection(strConnect); 
            conn.Open();
            Application.Run(new MainForm(conn));
        }
        catch(SystemException ex)
        {
                BugTracking.LogException(ex);
                Application.Exit();
        } 
}

static void UnhandledHandler (Object sender, UnhandledExceptionEventArgs
e) 
{
        //Inform user of a fatal error
        //Maybe MessegeBox.Show
        BugTracking.LogException(ex);
        Environment.Exit();
}

HTH,
Ayyappan Nair

-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Th�i Tr� H�ng
Sent: Wednesday, March 26, 2003 10:54 PM
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] Which way is the better way to trap all
unexpected exception !

Hi all , 
I'm looking for a way to trap all unexpected exception , and I found two
: 

- The first is trap at the appliction run point : (C# code)
     
[STAThread]
static void Main() 
{ 
        try
        {
                string strConnect="Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=db.mdb;Persist                 Security Info=False;";
                OleDbConnection conn=new OleDbConnection(strConnect); 
                conn.Open();
                Application.Run(new MainForm(conn));
        }
        catch(Exception ex)
        {
                BugTracking.LogException(ex);
                Application.Exit();
        } 
}

- The second is use OnThreadException (VB.NET code)

AddHandler Application.ThreadException, AddressOf Me.OnThreadException
...

Sub OnThreadException(ByVal sender As Object,_
                            ByVal t As
System.Threading.ThreadExceptionEventArgs)
        BugTracking.LogException(t;
        Application.Exit();             

End Sub


Could anyone explain me which way is better - I guest is is the same ?

And a further question - how can I determine when I must use
Appliction.Exit and when I can let user continue his job ? (In VB6.0 I
know a good mechanism to do that but I can not use this in .Net or I
don't know how to do that - may be ) 

Save me !

Th�i Tr� H�ng
Software Solution Center 
HPT Vietnam Co Ltd
tel : (084)  8.458518 - Ext : 327
mobile : 0908391763


************************************************************************

This email (including any attachments to it) is confidential, legally 
privileged, subject to copyright and is sent for the personal attention 
of the intended recipient only. If you have received this email in
error, please advise us immediately and delete it. You are notified that

disclosing, copying, distributing or taking any action in reliance on 
the contents of this information is strictly prohibited.Although we have

taken reasonable precautions to ensure no viruses are present in this 
email, we cannot accept responsibility for any loss or damage arising 
from the viruses in this email or attachments.We exclude any liability 
for the content of this email, or for the consequences of any actions 
taken on the basis of the information provided in this email or its 
attachments, unless that information is subsequently confirmed in 
writing. If this email contains an offer, that should be considered 
as an invitation to treat.

************************************************************************
*


==================================================================

Reply via email to