Thanks for commenting.

I found the MS Enterprise Library to be overkill for my projects and I ended up writing my own streamlined error logging and reporting components. I think the Libraries work best in larger projects than small to mid-sized ones.

If you need to throw an exception, put meaningful text in the exception, and then put the original exception into the innerexecption property!

Its not that hard! Or even better, use some type of ExceptionHandler framework like Enterprise LIbrary so you can log them to different areas. But it still boils down to being a defensive coder and writing proper unit tests to simulate what happens if hte network is not available. Etc etc etc. I could go on forever about this.

Good post.

What inspired me to write this article were the poor error messages I see in a vendor provided program at work. Their error messages do like you said, showing the what, why and how/who, but are ultimately next to useless because they’re so user unfriendly and packed with too much information. My take is that they should have greatly simplified the error information they were displaying to the non-technical users and logged the error details to disk where they could be reviewed and passed on by the IT staff.

It’s important to remember that the UI for error messages should have the same considerations for the user as the rest of your UI does.

I agree that a modal dialog error message should be reserved for the most critical errors. It shouldn’t be used for simply telling the user that they entered the wrong information or didn’t fill in a required field.

For this kind of user entry management in VB.NET apps I recommend using the ErrorProvider component as I described in the next article. For web based ASP.NET or LAMP apps, I recommend using AJAX techniques to produce similar results.