<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>