Roslyn-analyzers: Make CA1303 configurable or split it

Created on 19 Jun 2019  路  3Comments  路  Source: dotnet/roslyn-analyzers

Analyzer package

Microsoft.NetCore.Analyzers

Package Version

v2.9.3 (Latest)

Diagnostic ID

CA1303

Repro steps

  1. Create a new exception instance and pass a literal string to 'message' parameter

Expected behavior

It would be nice if this rule could ignore exceptions.

Actual behavior

Warning is reported because string is not retrieved from a resource table.

I'm not sure if there are already rules that can be configured, so this might not be an option. But splitting the rule into two, one for localization of exception and one for the remaining cases, might be a viable option.

4 - In Review Area-Microsoft.NetCore.Analyzers Feature Request

Most helpful comment

We would also appreciate the ability to treat constructor parameters on types that inherit from System.Exception differently from all other places that currently raise this diagnostic.

For exceptions that our application throws itself, either:

  1. They get caught further up and presented as nicely formatted error messages to the user, or
  2. They indicate that our code has made an incorrect assumption and needs to be changed.

In the former case, the message is irrelevant. In the latter case, the contents of the message are intended to be read by my team; even our end users who speak fluent English are typically not equipped to resolve the issue, so what typically happens is we get a copy-paste of a screenshot of the last-chance error dialog that we pop up as the application is on its way out the door.

It would be very awkward if this dialog were in a language that my team doesn't understand 馃槗.

It would be nice to keep the diagnostics for other situations, though.

All 3 comments

We would also appreciate the ability to treat constructor parameters on types that inherit from System.Exception differently from all other places that currently raise this diagnostic.

For exceptions that our application throws itself, either:

  1. They get caught further up and presented as nicely formatted error messages to the user, or
  2. They indicate that our code has made an incorrect assumption and needs to be changed.

In the former case, the message is irrelevant. In the latter case, the contents of the message are intended to be read by my team; even our end users who speak fluent English are typically not equipped to resolve the issue, so what typically happens is we get a copy-paste of a screenshot of the last-chance error dialog that we pop up as the application is on its way out the door.

It would be very awkward if this dialog were in a language that my team doesn't understand 馃槗.

It would be nice to keep the diagnostics for other situations, though.

I don't understand how #2640 solves this issue.

Are we supposed to list the constructors of all types that inherit from System.Exception to our .editorconfig file?

Thanks, added a different option: https://github.com/dotnet/roslyn-analyzers/pull/2642/files#diff-0dc34fda02de9acf20e36dedb5fe1f26R1500

dotnet_code_quality.excluded_type_names_with_derived_types = System.Exception
OR
dotnet_code_quality.CA1303.excluded_type_names_with_derived_types = System.Exception

Was this page helpful?
0 / 5 - 0 ratings

Related issues

paulomorgado picture paulomorgado  路  3Comments

paulomorgado picture paulomorgado  路  3Comments

Youssef1313 picture Youssef1313  路  4Comments

KrisVandermotten picture KrisVandermotten  路  3Comments

SixFive7 picture SixFive7  路  4Comments