DLL Error Handling

irish634

New member
Joined
May 28, 2013
Messages
4
Programming Experience
3-5
Good Morning,

I apologize in advance if this has been covered ad nausea. I am working in VB.Net 2008. I am creating a DLL for use in another application and also Microsoft Excel. The DLL is a series of mathematical equations in "Public Functions."

I am wondering how or if I should handle errors in the dll. I usually use this type of handler:

VB.NET:
On Error GoTo Error_Handler

    'Do something here

Error_Handler_Exit:
    Exit Sub   '(or function)

Error_Handler:
    'Handle the error somehow here
    Err.Clear
    Resume Error_Handler_Exit

I know I can take every precaution in the main app and the excel vba in order to make sure proper data entry so errors don't occur, but experience has taught me, if there is a hole, a user will find it.

Generally, I like to log errors in a table (if a database) or text, xml, or other type of file, but trying that in the dll doesn't seem quite right to me.

So my question is: How should I handle this?

Thank you,
Craig
 
Thank you. So if I read that correctly I use "Try, Catch, etc.," I would add a "Throw" under the catch handler. When I throw it, is it automatically send back to the app/vba that called it?

Sorry for the basic questions, just trying to learn a bit.
 
If you want to do anything about an exception then you use Try...Catch...Finally rather than On Error. Whether you actually want to do anything about an exception in a particular place depends on the circumstances. Catching an exception and then rethrowing it without doing anything else is doesn't actually achieve anything. In such a case you could simply not catch the exception and the result would be the same, i.e. the exception would bubble up the call stack and have to be caught elsewhere. That said, at least the Try...Catch block is an acknowledgement that an exception may be thrown and that specifically want it to bubble up and you haven't just ignored or forgotten about it.
 
I grasp the concept of the "try, catch, finally" and seems easy to implement (I learned on VBA so this is all a step up for me). I guess what I don't seem to get is how it goes from my dll, back to the app that's calling it. Am I reading your post correctly in that I could conceivably use Try... Catch.... Finally, and leave the catch blank and it automatically goes back to the caller?

I am fairly confident that I am capturing (in the app calling the dll) all the scenarios where an error might be raised (negative numbers, non numeric, etc.) but like I mentioned, experience has shown me if I have a hole somewhere, a user will find it. I suppose I am just trying to simplify my life when I get to the next phase of the project. I want to be able to handle exceptions/errors that might arise without the standard unhandled debug message box popping up.

Thank you for the replies.
 
If an exception is thrown then it automatically bubbles up the call stack until it hits a Catch block. If you want the exception to be passed from your library to the application then you do exactly nothing. Think about it. The .NET Framework is DLLs. If you call a Framework method and it throws an exception then it's up to your app to catch it, right? Your own DLLs are no different. If you were to put a Try...Catch in your library with an empty Catch block then that would basically be ignoring the exception and the application would never know that it occurred. You only catch an exception if you want to do something about it. If you don't want to do something about it then you don't do anything and it is up to the caller, or its caller, or its caller, etc, to catch the exception and do something about it. If noone catches the exception then the application crashes.
 
That makes sense. Thank you.
Last question and I can mark this resolved. One of my apps is a vba project in excel. I suppose I should add the proper library to be able to use try... catch... etc or will my "On Error Goto" suffice?

Thank you again for your answers.
 
Back
Top