Skip to content

Warn when catching Errors - #26794

Open
SolalPirelli wants to merge 5 commits into
scala:mainfrom
dotty-staging:solal/warn-catch-error
Open

Warn when catching Errors#26794
SolalPirelli wants to merge 5 commits into
scala:mainfrom
dotty-staging:solal/warn-catch-error

Conversation

@SolalPirelli

@SolalPirelli SolalPirelli commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Closes #25799

Final piece of the "stop catching stack overflow" puzzle: discourage everyone from catching errors that are likely to leave their program in a dubious state, or even to not be caught on Scala.js.

Review commit by commit

Have you relied on LLM-based tools in this contribution?

No

How was the solution tested?

New automated tests (including the issue's reproducer, if applicable)

*/
override def checkConformsExpr(actual: Type, expected: Type, tree: Tree, notes: List[Note])(using Context): Type =
val saved = ccState.ignoreClassifiers
try

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

review without whitespace


/** Use a class loader to load the plugin class.
*/
@nowarn("msg=Catching NoClassDefFoundError can lead to unexpected behavior") // backwards compat

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this one. loadClass throws ClassNotFoundException if it can't find the class. So we're catching errors that would happen if the class is found but its dependencies are not?

catch
case err: AssertionError =>
logger.log(Level.WARNING, err.getMessage())
false

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why assertion errors would be less severe than other errors (which use Level.SEVERE when logged just below)

@SolalPirelli
SolalPirelli force-pushed the solal/warn-catch-error branch 3 times, most recently from 9784d87 to 7250db7 Compare August 13, 2026 12:23
@SolalPirelli
SolalPirelli force-pushed the solal/warn-catch-error branch from 7250db7 to f547d48 Compare August 13, 2026 12:36
@SolalPirelli SolalPirelli added the needs-squashing PR whose commits should be squashed by the author or via the "Squash and Merge" button label Aug 13, 2026
@SolalPirelli
SolalPirelli force-pushed the solal/warn-catch-error branch from f547d48 to 8414e6a Compare August 13, 2026 13:15
@SolalPirelli

Copy link
Copy Markdown
Contributor Author

@sjrd does this look like a reasonable thing to do overall? before I send this for a proper review

@sjrd

sjrd commented Aug 13, 2026

Copy link
Copy Markdown
Member

That is way too strong to be a default, IMO. Not all Errors are unrecoverable. Typically only VirtualMachineErrors and ThreadDeaths are really bad. AssertionErrors basically must be caught by testing frameworks, at least.

Perhaps put this behind a linting flag.

@som-snytt

Copy link
Copy Markdown
Contributor

Catching Error inevitably leads to unexpected pain

Test frameworks are special cases.

I like the structure added for logging failed assertions. Everyone has a favored debug style, of course.

@SolalPirelli

Copy link
Copy Markdown
Contributor Author

Test frameworks are special cases.

Right, this is definitely a warning that expects users to silence it in specific "module boundary" cases where you do actually need to catch, say, AssertionError for a testing framework.

Putting it behind a lint flag is appealing, though I wonder what % of users actually need to catch Errors for their software to make sense. I'd expect most libraries and apps never do, since they depend on a framework that does it for them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-squashing PR whose commits should be squashed by the author or via the "Squash and Merge" button

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Replace catching StackOverflowErrors with a fuel

3 participants