.NET Answers

Everyone knows (or should know) that handling exceptions is  a fundamental feature of the .NET environment.  And most of the time if we don’t handle the exception ourselves the .NET environment will handle it for us.  However, letting the environment deal with the exception leaves us with absolutely nothing intelligent for our customers to report back to us when they call to report an error.

So, at a minimum, every application should have some way of getting some of the critical information back to the developer about what happened when the exception happened.  Log it to a file.  Log it to a database.  Send an email.  But do something.

Fortunately, DotNetNuke has an API call that we can make that will do all the hard work for us.  All we need to do is to make sure we call it.

So instead of putting in a typical try/catch block and writing our own logging functions in DNN, we would write:

try
{
    // Your standard code here
}
catch (Exception exc)
    //Module failed to load
{
    Exceptions.
        ProcessModuleLoadException(
        this, exc);
}

This will log the exception into the DotNetNuke event viewer located under the Admin menu for the portal where you can set it up to email the errors to you as well as logging them.

You may want to also log extra information into the event viewer.  For this, you’ll want to create a new exception object that takes the original error information and adds the additional information into the new exception.  You would then pass that new exception into ProcessModuleLoadException().

I strongly recommend that you surround the code in each of your methods with a try/catch block that calls ProcessModuleLoadException.  You really should put try/catch blocks in at a more module level.  But the entire method needs to be wrapped so that any unexpected errors that occur can be logged.