Can't `rethrow` in switch expression

[rubenferreira97]

Shouldn't be possible to rethrow in a switch expression since we can throw e?
Random example:

void main() {
  try {
    // some code that might throw
  } catch (e) {
    return switch (e) {
        Exception() => print('Return what this function asks for (void).'),
        Error() => throw e, //Works, but warning "Use 'rethrow' to rethrow a caught exception."
        _ => rethrow, // Error "Undefined name 'rethrow'"
    };
  }
}

Inside a catch clause I think we could allow a rethrow statement.

[munificent]

I've removed the "bug" tag since this is working as expected: rethrow is a statement and you can't use statements in switch expression bodies. In your example, the switch expression you have there doesn't do anything useful at all. It's in the body of a return but only the first case will ever complete normally, and print() evaluates to void. You're better off just writing:

void main() {
  try {
    // some code that might throw
  } catch (e) {
    switch (e) {
        case Exception(): return print('Return what this function asks for (void).');
        case Error(): throw e;
        case _: rethrow;
    }
  }
}

Switch expressions are not "the new better switch", they're switches you can use in expression position. In a statement position, like you have here, a switch statement is still the idiomatic approach.

Having said that, I can certainly imagine other places where you do have a switch in a catch body that returns values on most branches and where a switch expression would be useful. In those cases, it would be nice if we treated rethrow as an expression so you could use it here.

[srawlins]

See also (and maybe upvote) #2025

[rubenferreira97]

Having said that, I can certainly imagine other places where you do have a switch in a catch body that returns values on most branches and where a switch expression would be useful. In those cases, it would be nice if we treated rethrow as an expression so you could use it here.

@munificent yes that code is not my use case. Something like this:

Handler middleware(Handler handler) {
  return (context) async {
    try {
      return await handler(context);
    } catch (e) {
      context.read<Logger>.e(e); // log request exception
      return switch (e) {
        ServiceException(): mapServiceExceptionToResponse(e),
        //... others sealed exceptions
        _: rethrow, // rethrow unknown exceptions, errors, etc...
      };
    }
  };
}

I guess I will rewrite it like:

Handler middleware(Handler handler) {
  return (context) async {
    try {
      return await handler(context);
    } catch (e) {
      context.read<Logger>.e(e); // log request exception
      switch (e) {
        case ServiceException(): return mapServiceExceptionToResponse(e);
        //... others sealed exceptions
        case _: rethrow; // rethrow unknown exceptions, errors, etc...
      };
    }
  };
}

[lrhn]

(People really like the switch-expression syntax, to the point where they seem to prefer it over switch-statements in places where a statement would otherwise be the obvious choice. Maybe we should consider whether we can remove case from the switch statement too! Or maybe people just like expressions. That would explain a lot, in fact.)

[rubenferreira97]

People really like the switch-expression syntax, to the point where they seem to prefer it over switch-statements in places where a statement would otherwise be the obvious choice.

I can understand this sentiment; however, I really think that "the obvious choice" does not apply here. I believe there are use cases where expressions like return switch make sense. For example, when we have a switch statement full of returns and want to fallback to an exception (like here, where we map if possible, else throw/rethrow).

Another example:

switch (match.group(0)) {
  case "\n" :
    return r"\n";
  case "\"" :
    return r'\"';
  case "\b" :
    return r"\b";
  case "\t" :
    return r"\t";
  case "\f" :
    return r"\f";
  case "\v" :
    return r"\v";
  default:
    throw MatchException();
}

return switch (match.group(0)) {
  "\n" => r"\n",
  "\"" => r'\"',
  "\b" => r"\b",
  "\t" => r"\t",
  "\f" => r"\f",
  "\v" => r"\v",
  _ => throw MatchException(),
};

Maybe we should consider whether we can remove case from the switch statement too! Or maybe people just like expressions. That would explain a lot, in fact.)

I don't know if this was an ironic comment, but I would bet people would like that change 😁. I really hate the need to remember two different syntaxes every time I want to type some code. I assume Dart did not "unify" the switch statement because of breaking changes (old switch statements would not work). For example, Rust has a fully functional single switch syntax (match) since everything is an expression.

let result = match number {
  1 => {
    println!("One");
    "one" // I would like a keyword for this, like `yield "one"` since `return "one"` means return from the function 
  }
  2 => {
    println!("Two");
    "two"
  }
  _ => {
    println!("Other");
    "other"
  }
};

match number {
  1 => println!("One"),
  2 => println!("Two"),
  _ => println!("Other"),
}

Personally, I use switch statements because no better alternative is available. I don't like them for the following reasons:

1. Dart format bloats one liner cases switch statements can get much longer/harder to read dart_style#34
2. Now I have to remember two different switch syntaxes (Switch Statement case, : and ; vs Switch Expression no case, => and ,) and I will biasedly remember and use whenever possible the less verbose one
3. feels verbose with the need for case when it could easily be omitted

I also have a nitpick about switch expressions:

1. No way to have a code block in the case statement

final response = switch (e) {
  ServiceException() {
    print('Hi');
    mapServiceExceptionToResponse(e); // return mapServiceExceptionToResponse(e) would exit the function
  }
  _ => rethrow;
}

---

I feel this example speaks for itself:

Handler middleware(Handler handler) {
  return (context) async {
    try {
      return await handler(context);
    } catch (e) {
      context.read<Logger>.e(e); // log request exception
      switch (e) {
        case ServiceException():
          return mapServiceExceptionToResponse(e);
        case RequestException():
          return mapRequestExceptionToResponse(e);
        case AnotherException():
          return mapAnotherExceptionToResponse(e);
        case _:
          rethrow;
      };
    }
  };
}

// vs

Handler middleware(Handler handler) {
  return (context) async {
    try {
      return await handler(context);
    } catch (e) {
      context.read<Logger>.e(e); // log request exception
      return switch (e) {
        ServiceException() => mapServiceExceptionToResponse(e),
        RequestException() => mapRequestExceptionToResponse(e),
        AnotherException() => mapAnotherExceptionToResponse(e),
        _: rethrow,
      };
    }
  };
}

[Levi-Lesches]

Just ran into this again today. I feel the conversation ended on "use switch statements", followed by "let's make switch statements easier to use", but I think the original point was "it's weird that throw e is an expression, and rethrow is not".