C# Soup To Nuts: Exception Handling


Wow… after a great week out in Seattle, I’m back.  I’ve learned a lot and will be developing some new content around WPF and WPF/E in the future, but for now, it’s back to C# Soup To Nuts.


This week, I will be talking about C# Exception Handling.  These aren’t your fathers old Error Messages any more.  It’s structured, easy to understand and very customizable.  Watch this webcast to learn all about exceptions and how you can utilize them in your applications the right way.


As always, the demo code is attached.


Bill


 

C#StN-Session12DemoCode.zip


Comments (5)

  1. kitwest says:

    Great webcast. I’ve heard some recommendations that I take "exception" to.

    You said we should wrap certain code that’s prone to exceptional conditions, like file i/o, in try blocks — why wouldn’t we wrap ALL code in try blocks?

    Also, why bother to write custom exception classes when we can keep things simple by just using System.Exception whenever we need to throw a new exception?

  2. wsteele says:

    Interesting comments.  Let’s answer the last one first.  Writing custom exception classes allows you to add your own business logic to the exception.  For example, some exceptions can be handled or logged in different ways then others.  Using the standard System.Exception (or System.ApplicationException) you can’t do that.

    Now, for the first one.  I recommend using exception handling where you need it.  In most cases, you might not need to have exception handling becuase it can be handled by something higher up in the stack.  For example, if I wrap an exception around a form object, then I don’t need to make sure everything in that form has an exception handler as well, becuase it will "default" to the caller’s exception handler.

    Hope that helps,

    Bill

  3. kitwest says:

    I’d love to see how you set up an exception handler for a form. I’ve been using try blocks for each event handler.

    I’d also love to see practical examples of business logic in custom exceptions. Is there some "best practice" or pattern that would involve custom exception classes? (I’ve seen uses that left me wondering why all the extra code was written, but never an application that made me think I could really use this to make applications better.)

  4. kitwest says:

    Someone asked during your webcast how to tell what line caused an exception. I like to log ex.StackTrace (to a db table), since it has that detail, when I can:

       private void Form1_Load(object sender, EventArgs e)

       {

         try

         {

           MyExceptionalMethod();

         }

         catch (Exception ex)

         {

           MessageBox.Show(ex.StackTrace);

         }

       }

       private void MyExceptionalMethod()

       {

         throw new Exception("Failing here.");

       }

  5. kitwest says:

    Hi Bill,

    Now I *really* need a way to catch exceptions at the form level, and here’s why: I need my client to show a Logon form when the authentication ticket expires at the server. My general-purpose exception handler is in a dll called by the UI, so I can’t pop up a form there without having a circular reference. I suspect I want all my forms to inherit from a base that knows how to catch my ExpiredTicketException and prompt for the fresh logon. So there’s a practical example I was asking for, in my face. 🙂

    So how would you suggest I catch all exceptions for a form in one place??

    Thanks,

    Kit

    ps – I enjoyed your rant on flight taxation — Big Brother gets it wrong so often, we need more people to speak up and set him straight!