Throwing exceptions in switch statements when no specified case can be handled

Question

Let\'s say we have a function that changes a password for a user in a system in an MVC app.:

public JsonResult ChangePassword
    (string username, string curren         


        

Answer 1

Validating runtime constraints is usually a good thing, so yes, best practice, helps with 'fail fast' principle and you are halting (or logging) when detecting an error condition rather than continuing silently. There are cases where that is not true, but given switch statements I suspect we do not see them very often.

To elaborate, switch statements can always be replaced by if/else blocks. Looking at it from this perspective, we see the throw vs do not throw in a default switch case is about equivalent to this example:

    if( i == 0 ) {


    } else { // i > 0


    }

vs

    if( i == 0 ) {


    } else if ( i > 0 ) {


    } else { 
        // i < 0 is now an enforced error
        throw new Illegal(...)
    }

The second example is usually considered better since you get a failure when an error constraint is violated rather than continuing under a potentially incorrect assumption.

If instead we want:

    if( i == 0 ) {


    } else { // i != 0
      // we can handle both positve or negative, just not zero
    }

Then, I suspect in practice that last case will likely appear as an if/else statement. Because of that the switch statement so often resembles the second if/else block, that the throws is usually a best practice.

A few more considerations are worthwhile: - consider a polymorphic approach or an enum method to replace the switch statement altogether, eg: Methods inside enum in C# - if throwing is the best, as noted in other answers prefer to use a specific exception type to avoid boiler plate code, eg: InvalidEnumArgumentException