<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Apr 24, 2024, at 10:50 PM, Kevin Bourrillion <kevinb9n@gmail.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">Hey Angelos!
<div><br>
</div>
<div>For whatever my take is worth here, I'm also skeptical. I think the bar for adding another way to catch exceptions should be really high, and the benefits here wouldn't clear it. I just don't expect the nested switch-in-try will be painful enough
<i>often</i> enough.</div>
<div><br>
</div>
<div>This feature would only be applicable when the whole possibly-exception-producing code can fit into a single expression in the switch header . . .</div>
</div>
</div>
</blockquote>
<br>
</div>
<div>This raises a very good question: what do we expect the "whole possibly-exception-producing code” to look like in practice?</div>
<div><br>
</div>
<div>I conjecture that the attractive situation for using switch-with-“case throws"-clauses will NOT involve arbitrarily large expressions that might need to be refactored, but rather a single method call (or possibly an expression with a single operator) where
all argument expressions are variables or constants, rather than other stuff that might cause exceptions.</div>
<div><br>
</div>
<div>But I am not sure. So maybe this is a conjecture that could be researched.</div>
<div><br>
</div>
<div>—Guy</div>
<div><br>
</div>
</body>
</html>