Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Visual Studio.NET / Extensibility / October 2005

Tip: Looking for answers? Try searching our database.

JetBrains Resharper - Techniques to make an Unhandled Exception dialog appear for a VSIP package.

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
DarenYong - 26 Oct 2005 00:19 GMT
Hello,

I'd like to say that I love Resharper, I think it is a great product.

I have been using the new Resharper beta under VS 2005 and noticed that it
displays a very nice Error dialog if something goes wrong.

Does anyone know the techniques to install an error dialog for unhandled
exceptions in a package?

I tried using AppDomain.UnhandledException += new delegate(myhandler) but
this does not seem to work.

I don't know if I need to resort to some kind of unmanaged C++ technique,
or if there is a VSIP interface with a SINK (advise/unadvise) that I am missing.

The only other method I can think if is to manually write a try/catch block
around every visual studio interface that my package implements (the 'surface
area' of my application).

This idea is unappealing, as I must remember to code a try/catch block around
all my managed code to make sure errors are trapped and a nice dialog explaining
the situation appears (with a stack trace, etc.).

Any help greatly appreciated!

Best regards,
Daren.

Captaris
Dustin Campbell - 26 Oct 2005 01:19 GMT
Hi Daren,

> I tried using AppDomain.UnhandledException += new delegate(myhandler)
> but this does not seem to work.

In our DXCore product, we use this successfully from an add-in but I
have not been able to get this to work from a managed package. It
appears that the exception is handled by Visual Studio before the CLR
can raise the UnhandledException event. I suspect that Visual Studio's
default exception handler is simply disabled for add-ins.

If you decide to go the add-in route to use this event (as I suspect
ReSharper did as well), here are some tips and code to help you:

AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(ehUnhandledException);

private void ehUnhandledException(object sender,
UnhandledExceptionEventArgs e)
{
 if (e.ExceptionObject == null)
   return;
 if (!e.ExceptionObject.GetType().IsSubclassOf(typeof(Exception)))
   return;
 if (e.ExceptionObject.GetType() ==
typeof(System.Threading.ThreadAbortException))
   return;

 Exception lException = (Exception)e.ExceptionObject;

 // Do stuff with the exception...
}

There are two gotchas to keep in mind when using this event:

1. You'll see *every* unhandled .NET exception. So, you might see them
from other third-party products. If you only want to see exceptions
from your package, you might need to walk the call stack using the
System.Diagnostics.StackTrace class.

2. ThreadAbortExceptions are automatically re-raised by the CLR so you
could potentially see a lot of these. So, you might consider ignoring
exceptions of this type.

Signature

Best Regards,
Dustin Campbell
Developer Express, Inc

DarenYong - 26 Oct 2005 02:25 GMT
Hello Dustin,

This advice was just what I was looking for.

Thanks for the code and tips, they are much appreciated!!

Cheers!
Daren.
DarenYong - 26 Oct 2005 20:34 GMT
Hello Dustin,

I tried to reproduce catching an unhandled exception using a sample AddIn
(created using a VS wizard), but it does not seem to work.

When I click on MyAddIn1 from the Tools menu, I see the "Exec" message box,
but then nothing else occurs (no messagebox - nothing).
(I can debug the addin and see the exception being thrown, but after the
throw it is lost in unmanaged code, and I never hit the breakpoint on the
first line of the unhandled exception handler).

I tried throwing an exception from my package and this is not caught either
(it goes to the regular VS global error handler).

Here is my Toolbar command for my addin:

        public void Exec(string commandName, vsCommandExecOption executeOption,
ref object varIn, ref object varOut, ref bool handled)
        {
            handled = false;
            if(executeOption == vsCommandExecOption.vsCommandExecOptionDoDefault)
            {
                if(commandName == "MyAddin1.Connect.MyAddin1")
                {
                    MessageBox.Show("Exec");
                    throw new InvalidOperationException();
                    handled = true;
                    return;
                }
            }
        }

First line of OnConnection():

        public void OnConnection(object application, ext_ConnectMode connectMode,
object addInInst, ref Array custom)
        {
            AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

The unhandled exception handler:

        void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs
e)
        {
            if (e.ExceptionObject == null)
                return;
            if (!e.ExceptionObject.GetType().IsSubclassOf(typeof(Exception)))
                return;
            if (e.ExceptionObject.GetType() == typeof(System.Threading.ThreadAbortException))
                return;

            Exception lException = (Exception)e.ExceptionObject;

            MessageBox.Show(lException.Message);       
        }
Dustin Campbell - 26 Oct 2005 21:45 GMT
> I tried to reproduce catching an unhandled exception using a sample
> AddIn (created using a VS wizard), but it does not seem to work.
[quoted text clipped - 7 lines]
> I tried throwing an exception from my package and this is not caught
> either (it goes to the regular VS global error handler).

Correct. If an exception gets handled by Visual Studio it isn't
unhandled anymore. Visual Studio is designed to recover from faults
like these so that it can't be easily crashed by a package or add-in.

Here's what happens, when an exception is thrown from a COM-Callable
Wrapper (CCW) like a managed add-in or package, that exception gets
turned into an appropriate HRESULT by the CLR. In addition, the CCW
supports IErrorInfo so that COM can get the error message of the
exception and any other details. So, if your exception gets back to
Visual Studio, it gets eaten up.

To deal this, we wrap try/catch blocks around major entry points into
our add-in and package. For example, we have try/catch blocks around
the OnConnection and OnDisconnection so that we can display a nice
exception dialog if something goes wrong during start up or shut down.
In addition, every event and sink listened to in our architecture goes
through one central location so this is easy to wrap a try/catch around.

UnhandledException *can* be fired if the exception occurs in pure .NET
code. Exceptions raised from a .NET background thread is a great
example.

So, if Visual Studio calls your method, try/catch blocks are necessary
to display a meaningful dialog. But, UnhandledException can be used to
catch any exceptions that Visual Studio would miss.

I hope that explains the situation!

Signature

Best Regards,
Dustin Campbell
Developer Express, Inc

DarenYong - 27 Oct 2005 00:29 GMT
Ah - thanks for clearing that up!

Best regards,
Daren.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.