27 lines
1.1 KiB
Plaintext
27 lines
1.1 KiB
Plaintext
|
=== On 2017-09-05T14:35:39Z Duncan Pocklington Wrote:
|
||
|
|
The C# implementation of this rule catches one invalid case:
|
||
|
|
|
||
|
|
|
||
|
|
{{new Exception(...)
|
||
|
|
|
||
|
|
}}
|
||
|
|
|
||
|
|
|
||
|
|
However, this isn't valid syntax in VB.Net (i.e. it will be reported as a syntax error in the IDE).
|
||
|
|
|
||
|
|
|
||
|
|
For this rule to be useful in VB it would need to be more complex i.e. check for exceptions that are created and assigned to a variable/field/property that are not then returned, passed to another method, or returned, or thrown.
|
||
|
|
|
||
|
|
|
||
|
|
\[~jeanchristophe.collet] should we just park this issue for VB for now?
|
||
|
|
|
||
|
|
=== On 2017-09-05T15:02:19Z Jean-Christophe Collet Wrote:
|
||
|
|
Agreed, work on this should be postponed for now.
|
||
|
|
|
||
|
|
=== On 2018-10-05T09:08:08Z Loïc Joly Wrote:
|
||
|
|
The current implementation for C# is just checking that the exception object is used somehow. But in VB.NET, it's not possible to create an object without using it, so the rule would never be triggered.
|
||
|
|
|
||
|
|
|
||
|
|
If the C# implementation tracked the value to see if it was really thrown (requiring inter-procedural symbolic execution), then it would make sense to reactivate this rule for VB.NET too.
|
||
|
|
|