add a quick action to remove a try catch

[stephane-archer]

try {
   foo();
} catch (e)
{
print(e);
}

to

 foo();

by quick fix the try

[paudel-milan]

Hey @stephane-archer,
I’d like to work on this issue. Could you please assign it to me? Also, if you could provide a bit more clarification on the expected behavior of the quick action, that would be really helpful.

Looking forward to your guidance!

[FMorschel]

@paudel-milan neither @stephane-archer nor I are working at Dart so we can't assign this to you, but you saying here you'll work on this should be fine. I've contributed some times now already so if you need any help with this please feel free to email me (my bio), PM me wherever or ping me here.

I'd also wait on some answer from the team for how they believe this should be handled (tagging some people below for this). Mainly considering what cases is this going to cover (please review if forgot something):

• When catch has no body
• When catch does nothing besides "hiding" the error (as above)
• When catch throws another error (maybe doing something else) (consider if rethrow should be different)
• When multiple catches exist (using on)

CC @bwilkerson @srawlins

[srawlins]

@FMorschel I like all your categories. To me it seems safe to only offer the quick fix when the catch body does nothing. Like it's literally empty, or just calls rethrow. But even an empty or rethrow can change the behavior of the code:

try {
  // ...
} on StateError catch (_) {
  rethrow; // or even empty body.
} catch (_) {
  // ...
}

When you remove the "first catch" (really, an on-clause), you change what exceptions may enter the second catch.

If the request is instead to remove a whole try/catch block, I'm hesitant. @bwilkerson will know our general priorities and goals here. This seems to me a very specific situation. Like we similarly don't offer an assist to extract the then-body out of an if-statement, or the else-body.

As far as an assist goes (a code action not triggered by a static lint/warning), I don't know that we would populate the context menu with this assist. As far as quick fixes though, like if there is a warning or a lint saying that a catch-clause or something is unnecessary, or dead code, then there is more value in offering the fix.

[bwilkerson]

I'm not sure I completely understand the original request, but as noted above we'd need to answer the questions of what this assist should do if

• the statement is incomplete
• the statement has a finally clause
• one or more of the catch clauses is non-empty

In almost every set of criteria that I can think of (other than when there's only an empty finally clause) this would change the semantics of the code. While I'm not opposed to having assists that change the semantics, I think we tend to require a fairly compelling use case before adding them. I'm not seeing a strong use case for this.

As a workaround, a user can copy the content to be preserved and paste it over the structured statement that contained it, so it isn't clear that it saves much effort.

Also, we don't have equivalent support for extracting code from any other structured statement (if, while, etc.). We'd probably want to add all of them if we added any of them.

Without a compelling use case I'm guessing that we'll say no to this request.

[paudel-milan]

Hey everyone, thanks for the detailed explanations!
I see that this quick fix might not be a priority due to the potential semantic changes and the lack of similar refactoring assists for other structured statements. That makes sense.

I really appreciate the insights from @FMorschel, @srawlins, and @bwilkerson. Since I’m a beginner looking to contribute to Dart, could you suggest any open issues that align better with the current priorities and would be a good starting point for me? I'd love to work on something that adds real value to the project while helping me learn more.

Looking forward to your guidance, and thanks again for your time!

[FMorschel]

I'll take a look at some issues later and tag you on them.

[stephane-archer]

My original usage was that I wanted to remove a try statement quickly so that the caller could deal with the exception rather than the current function. the goal is to quickly change the code, not to preserve the current behavior.
deleting the try { line and then all the corresponding catch statements can be a pain to do without missing a { or }