1

I'm creating an add-in for Solidworks EPDM (example from API help). This is a class library (.dll) project which is added to EPDM and allows some custom functions to be added to the program.

I want to add logging for unhandled errors so that when an exception is caused by my add-in (as opposed to by the Solidworks EPDM program itself) I can be notified of it and try to fix it.

I'm quite new to all of this (and by all of this I mean VB.NET as a language, programming anything other than macros in VBA, structured exception handling, error logging, etc) and I'm trying to follow MSDN How To: Log Exceptions in Visual Basic but the instructions for logging unhanlded exceptions don't seem applicable to class library projects.

Specifically, I don't know how to get past step 3:

To log an unhandled exception
1. Have a project selected in Solution Explorer. On the Project menu, choose Properties.
2. Click the Application tab.
3. Click the View Application Events button to open the Code Editor.
This opens the ApplicationEvents.vb file.

The View Application Events button is greyed out for class library projects.

enter image description here

So, is there another way to add logging for unhandled exceptions in class library projects? Or, another way to access the ApplicationEvents.vb file for class library objects? I've tried searching for either, and have yet to find a solution that would allow me to log unhandled exceptions.

CBRF23
  • 1,340
  • 1
  • 16
  • 44
  • 1
    There are no unhandled exceptions in this scenario, the host program will get them. It will surely display *something* but rarely good enough to help you diagnose the failure. Put a Try/Catch in your DoCmd() method, don't forget to Throw it again so the host knows it went wrong. – Hans Passant Jul 30 '15 at 17:12
  • @HansPassant - so you're recommending a try catch with a generic `catch ex as exception`, log it and re-throw it? – CBRF23 Jul 30 '15 at 17:20
  • 1
    The "best" practice should be to make your code aware of *any* exception that could happen within it; either to handle it inside your add-in if it can/should, or to document it so the calling code can handle it if not. Having a global `try - catch` can help during developing and testing phases, but not for real scenarios; once you get all exceptions that can happen, you should get rid of it. – Josh Part Jul 30 '15 at 17:56

1 Answers1

2

This is a very basic example but wrap your code with Try/Catch in the only two interface methods (host "callbacks") that IEdmAddIn5 defines and which your add-in class must implement.

Public Sub GetAddInInfo(ByRef poInfo As EdmAddInInfo, ByVal poVault As IEdmVault5, ByVal poCmdMgr As IEdmCmdMgr5) Implements IEdmAddIn5.GetAddInInfo
    Try
       ...
    Catch ex As Exception
       ' Handle exception...
    End Try
End Sub

Public Sub OnCmd(ByRef poCmd As EdmCmd, ByRef ppoData As System.Array) Implements IEdmAddIn5.OnCmd
    Try
       ...
    Catch ex As Exception
       ' Handle exception...
    End Try
End Sub

I would ordinarily agree with @Hans Passant about re-throwing the exception but I generally have found that to be problematic with an EPDM add-ins as it can cause the COM host to crash.

blins
  • 2,515
  • 21
  • 32
  • This is essentially what I ended up doing, although I am re-throwing any exceptions that I don't know how to handle. I figure I would rather crash EPDM then put it into an unknown state. – CBRF23 Aug 04 '15 at 12:18
  • IMO, I would just handle any exception. Also, remember that EPDM will throw COMExceptions by design for certain API methods if/when a call fails for certain seemingly benign reasons so watch for those gotchas in the documentation. In such cases usually wrapping the method call with an additional 'try/catch(COMException ex)...' is merited so that you can handle the expected HRESULT (the value correlates to an error message EPDM would otherwise show like "File format boy recognized.") – blins Aug 04 '15 at 13:02
  • So where I'm at now is basically logging and swallowing anything non-fatal and unexpected. But exceptions like `StackOverflowException`, `OutOfMemoryException`, etc. I use `Throw()` to push back to EPDM as those are pretty much assuredly fatal ;) – CBRF23 Aug 04 '15 at 13:07