Exceptions and controlling program flow

Continuing the discussion from Possible to make “return false” “travel upward” in a chain of functions?:

Opinions seem to vary among developers as to when exceptions should or shouldn’t be used. An area of disagreement that seems to come up a lot is with validation. The argument against using exceptions in this case is that incorrect input from the user is to be expected, and therefore failing validation doesn’t constitute an ‘exceptional’ situation. From the quote above though, it seems that from Stroustrup’s point of view, validation exceptions would be OK.

I’d be interested in hearing some opinions about this, and any arguments you might have for or against.

First of all, +1 for “Reply as new topic.” :smile:

This argument seems to lean on a particular interpretation of the word “exceptional”. Some take it to mean that an exception must be a rare or unexpected event. And, admittedly, those are the top definitions when I look it up in webster. The problem, however, is that people like Stroustrup, the creator of C++, state quite explicitly that this isn’t how “exceptional” is meant to be interpreted.

I’d also argue that we should make a point to be pragmatic. We should be less concerned with how something was named and more concerned with the behavior it provides.

I would think it varies slightly depending on context. Let’s say we have an EmailValidator and a NotificationMailer. The validator’s job is to check whether a value is a valid email, and the mailer’s job is to send an email. If we give them both an invalid email, which should throw an exception? Stroustrup seems to suggest that the determining factor is whether “the system couldn’t do what it was asked to do.” Could the validator still check the validity of an invalid email? Sure. Of course. It would return a value indicating that the email was not valid. Could the mailer still send a message to an invalid email? Well, no. An invalid email would prevent the mailer from doing what we asked it to do. Exception.

2 Likes

To this point, as I believe that is a good example, and I’ll just build on it.

If you send or fail to send the correct arguments to your EmailValidator, I don’t see a problem throwing an InvalidArgument Exception, or a MissingArgument Exception (where the message fills you in on which argument is invalid or missing).

When I refer to InvalidArgument, I’m not referring to an invalid email address, but that an email address wasn’t given at all! Instead a class object was received, or a boolean, or a type that doesn’t make sense for the validator to deal with.

1 Like

Thanks guys, I appreciate both the replies.

Put like that, it seems a lot more clear-cut. That’s very helpful, thanks! :slight_smile:

golang has a function called panic which you call if you really can’t go on with what you were doing.
Besides panic golang also has Errors, which are a datatype describing -as you would guess- an error. These can be returned from a function and dealt with in the calling function. These are not exceptions, they are just strings wrapped in an Error wrapper.

So back to @Jeff_Mott 's example on the email address, the validator should probably return an Error (or false, depending on how you want to implement it) whereas the mailer should panic because it doesn’t know what to do.

To me these are more apt names than exception and better describe what’s going on. Maybe it helps someone else as well.