Why ever use exception throw (in C#) except for Class Library development?

Question

Why would I ever throw exceptions in code? (except for one specific scenario where I am developing a class library which the consumers of it, will not want / be able to change).

To be more specific, is there any reason to do this:

class EmailSender
{
   public void SendEmail(string recipient, string subject, string content)
   {
       if (string.IsNullOrEmpty(recipient))
       {
           throw new ArgumentNullException("exception text...");
       }

       // Send the email
   }

}

Instead of this:

class EmailSender
{
   public bool SendEmail(string recipient, string subject, string content)
   {
       bool result = false;

       try
       {
           if (string.IsNullOrEmpty(recipient))
           {
              logger.Error("Error text...");
           }
           else
           {
              // Send the email
              result = true;
           }
       }
       catch (Exception ex)
       {
           logger.Error(ex);
       }

       return result;
   }
}

Take into account that this class is in-house code and not something I am going to ship as a DLL or an open source project.

Answer 1

Are you asking why not always handle the error inside the same method the error is detected?

It is rarely the case that you can handle an error at the same level as where the problem is detected, it is only possible because you example is contrived. For example, what if the "send the mail" logic contains multiple method calls:

VerifyAdresses(recipient);
ConnectToSmtpServer();
PostMessage();

What if an error is detected in VerifyAdresses or ConnectToSmtpServer? If the method just logs the error and continues happily (as in your example), the PostMessage will be execute in any case, probably with a much more severe error as result.

You need to handle errors at the level where it is possible to gracefully recover. For example you can handle error in the mailing logic by not sending the mail. But you cannot gracefully handle an error locally inside VerifyAdresses() if that error prevents the whole operation of sending an mail. You need to be able to drop back up the call stack (possibly multiple steps) to the level where the error can sensibly be handled.

---

Edit: OK, you are really asking why not use C-style success/error result codes instead of exceptions. This discussion have been beaten to death, but suffice to say that the framework have made the choice for you. Result codes consistently used may in theory be as good as exceptions (if much more tedious and error prone), but since the framework already uses exceptions, it would be incredibly confusing and a waste of resources to use both exceptions and result codes in the same code base.

Answer 2

Software generally consists of layers of functionality. (i.e. the application layer, the persistence layer, the network layer, the database layer, etc.)

A "library" is a layer of functionality which has been distanced from your code by having been moved into a separate binary file, but this is just a technicality, the point is that it is just another layer of functionality.

A layer of functionality generally communicates errors to the layer above by throwing exceptions.

So, if all of the software that you are writing lives in a single layer as thin as a crispy pizza dough, then yes, I suppose there may be no need for you to ever throw an exception.

But if you ever do anything non-trivial in your career, then you will of course work simultaneously at different layers, and therefore you will have a need to throw an exception in one layer, to be caught (or not) by a layer above.