Where are Assertion methods in R#4.0?

Hello,
I am using a custom assertion method, and have a problem with it.

LoginPart loginPart = App.Current.MainWindow.CurrentPart as LoginPart;
Utils.Assert(loginPart != null);
loginPart.SetStatusText(LocResources.LoginPartIncorrectIdentification, true);

Of course, on the last line, I got a warning "Possible System.NullReferenceException" on "loginPart".
So I tried to add a custom Assertion method to R#4.0 (build 783), but couldn't find this anywhere in the options. I am sure this was possible before ?

So I googled a little, and added:
]]>
to my .resharper file, both in solution and project files since I don't know which one I had to modify, but to no avail.

Is there a fix to this in Resharper 4?

Thank you,

--
Julien

Edited by: MrJul on Apr 25, 2008 6:40 PM

13 comments
Comment actions Permalink

Hello MrJul,

In ReSharper 4 we changed this, and now you can annotate methods right in
code:


public static void Assert(
bool condition, string message)

Those attrbitues can be standard annotations provided by ReSharper, which
you can get by referencing JetBrains.Annotations.dll from install folder
(you can copy it wherever you like).
Alternatively, you can go to Options / Code Inspection / Code Annotations,
hit "Copy default implementation" and paste it in your project. You can then
change namespace as you wish, but if you change it, be sure to revisit Code
Annotations options and enable them, and probably set as default.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


IR> Hello,
IR> I am using a custom assertion method, and have a problem with it.
IR> LoginPart loginPart = App.Current.MainWindow.CurrentPart as
IR> LoginPart; Utils.Assert(loginPart != null);
IR> loginPart.SetStatusText(LocResources.LoginPartIncorrectIdentificatio
IR> n, true);
IR>
IR> Of course, on the last line, I got a warning "Possible
IR> System.NullReferenceException" on "loginPart".
IR>
IR> So I tried to add a custom Assertion method to R#4.0 (build 783),
IR> but couldn't find this anywhere in the options. I am sure this was
IR> possible before ?
IR>
IR> So I googled a little, and added:
IR> IR> Parameter="0" Type="IS_TRUE" /> IR> IR> to my .resharper file, both in solution and project files since I IR> don't know which was I had to modify, but to no avail. IR> IR> Is there a fix to this in Resharper 4? IR> IR> Thank you, IR> IR> -- IR>]]> Julien


0
Comment actions Permalink

Thank you for your quick answer.

This system is more extensible but I don't feel like referencing another assembly or adding classes unrelated to my code just to avoid a Resharper warning... I think the old way was better, maybe I just have to get used to it.

--
Julien

0
Comment actions Permalink

Hello MrJul,

Well, it is not just extensibility.

We wanted to annotate standard libraries so that ReSharper's analysis engine
can know about null/not null, formatting, etc about symbols from standard
framework. We also wanted to unify the system, and make it easier to annotate
your own code. Now it is just a matter of attribute in your code, instead
of clumsy options. Also, as annotations are part of source code, they are
(almost) always in synch with code. That said, every developer using ReSharper
for a project has the same configuration in regard to annotation.

For example, you had a method Log(string message) in class Logger, and then
you decided to add a formatting overload like Log(string format, params object[]
args). You annotate it right in place and everybody can now see ReSharper's
warnings about missing argument placeholders.

As for "adding classes unrelated to my code", this is something I don't quite
get. There is ConditionalAttribute which controls another tool - the compiler.
And ExtensionAttribute which is new to C# 3.0. You have to reference System.Core
or redeclare the same attribute in your source to use extension methods,
which is again a feature of tool. We also have SuppressMessageAttribute -
it controls FxCop, yet another tool. So, is this a matter of vendor name,
or namespace name? If you put ReSharper's attributes into System.Diagnostics.CodeAnalysis
namespace, will it make them "better"? Is it "non-standard" namespace JetBrains.Annotations
that makes you feel uncomfortable?

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


M> Thank you for your quick answer.
M>
M> This system is more extensible but I don't feel like referencing
M> another assembly or adding classes unrelated to my code just to avoid
M> a Resharper warning... I think the old way was better, maybe I just
M> have to get used to it.
M>
M> --
M> Julien


0
Comment actions Permalink

Hello,

Thanks for clarifying some points. I admit that with attributes, everything is easily synchronized, that's clearly an advantage.

What bothered me at first is that I had to include another assembly. Since many of the projects in my solution will use annotations, it seems quite logical to put all of them in another assembly, may it be the default JetBrains.Annotations or a custom one. Nothing wrong with adding an additional assembly, but it had to be deployed with the application, which seems quite odd since the attributes within it are only use for code verification...

Then I thought a little more, copied the default annotations implementation in my custom assembly, and added a in front of every attributes. That way, I can easily undefine the conditional constant in order to remove any dependency on the annotations assembly when building the projects for deployment.

So everything is perfect, thanks JetBrains :)

--
Julien

Edited by: MrJul on Apr 26, 2008 9:47 PM

Edited by: MrJul on Apr 26, 2008 9:50 PM

0
Comment actions Permalink

"Is it "non-standard" namespace JetBrains.Annotations
that makes you feel uncomfortable?"

Yup, because if this is an actual dependency on the JetBrains assemblies then we can't build on a machine without R# installed, and because if this is just a dependency on the string "JetBrains.Annotations" then people think R# has become a dependency. Both can be a problem in some environments, as much as logically speaking the second possibility isn't really a problem at all.

0
Comment actions Permalink

Also, many large (i.e. deep pocket) companies have very skittish lawyers about using third-party software in their products or own applications. Sometimes even using some Microsoft software is forbidden (such as the Enterprise library).

0
Comment actions Permalink

First of all, thanks for making the source available.

However, there are improvements that can be easily made:

1) The cref to String.Format generates an error:

Error 1 Warning as Error: Ambiguous reference in cref attribute: 'String.Format'. Assuming 'string.Format(string, object)', but could have also matched other overloads including 'string.Format(System.IFormatProvider, string, params object[])'.

2) The public members are undocumented and also generate errors if XML documentation is generated.

3) Can you provide some examples of using the Assertion and AssertionCondition attributes?

4) The casing and use of underscores in AssertionConditionType is contrary to MS guidelines. Can these spellings be corrected by a user without breaking RS? (I think so, but if so it would better for RS to also change your implementation). It also might be a good idea to add numeric related values (IsZero, IsNan, ...)

5) TerminatesProgram is different from TerminatesThread. I could see a use for both.

6) Was CannotBeNull renamed to NotNull or is my memory foggy?

7) For CannotApplyEquality, I don't think there should be an exception for comparison to null. The coder should use ReferenceEquals with one of the parameters null instead. Also, what are the semantics if the coded used Compare?

8) BaseTypeRequired.BaseTypes should not return an array -- that approach is slow since C# creates and populates a new array eery time the property getter is used. It should probably return a readonly sorted list or dictionary.

9) The Can/NotNull attributes should also be allowed on AttributeTargets.ReturnValue

PS: Does RS implicitly know that event fields may be null, and that they shuld be copied to a local variable before being used to notify listeners?

10) It would be nice to have some async support. For a minimal example, ChangesMustBeInterlocked to indicate the entity can only be modified via the InterLocked support. Things beyond that simplicity are also great to have, but best left for RS 5.

0
Comment actions Permalink

Some additional coding problems:

11) the attribute classes should be sealed

12) I think the "public BaseTypeRequiredAttribute ( Type baseTypes )" constructor is redundant, as the same usage can be captured via the constructor that uses "params Type[]". If I am right, maybe RS5 should include a check for this issue?

Since the project I am working does not allow (via TeamFoundation check-in policies) for properties that return an array, can you provide infomation as to what other possible reurn types RS will support? Hopefully, something like IEnumerable]]> should be safe at a minimum.

0
Comment actions Permalink

Hello Jeremy,

You can overcome the problem of assembly dependency by including attributes
in source code, right into project. And you choose whatever namespace you
like, not just JetBrains.Annotations (you have to configure it in options,
though). So, there are no problems left, right? :)


Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


JG> "Is it "non-standard" namespace JetBrains.Annotations that makes you
JG> feel uncomfortable?"
JG>
JG> Yup, because if this is an actual dependency on the JetBrains
JG> assemblies then we can't build on a machine without R# installed,
JG> and because if this is just a dependency on the string
JG> "JetBrains.Annotations" then people think R# has become a
JG> dependency. Both can be a problem in some environments, as much as
JG> logically speaking the second possibility isn't really a problem at
JG> all.
JG>


0
Comment actions Permalink

Hello Brian,

BS> 1) The cref to String.Format generates an error:
BS> 2) The public members are undocumented and also generate errors if
BS> XML documentation is generated.

Will fix.

BS> 3) Can you provide some examples of using the Assertion and
BS> AssertionCondition attributes?


public static void Assert(
bool condition, string message)

BS> 4) The casing and use of underscores in AssertionConditionType is
BS> contrary to MS guidelines. Can these spellings be corrected by a
BS> user without breaking RS? (I think so, but if so it would better for
BS> RS to also change your implementation). It also might be a good idea
BS> to add numeric related values (IsZero, IsNan, ...)

I will check, but I suppose user cannot change casing and still have ReSharper
understand the attributes. We will consider changing the casing.

BS> 5) TerminatesProgram is different from TerminatesThread. I could see
BS> a use for both.

This attribute means, that method never returns. For example:

if (a == null)
NeverReturns();
a.Do();

If NeverReturns is marked with attribute, warning about possible NRE will
not be issued.

BS> 6) Was CannotBeNull renamed to NotNull or is my memory foggy?

Previously we didn't force attribute names, you could set in options whatever
you want. Currently we allow only namespace to be changed, due to some performance
limitations and feature requirements.

BS> 7) For CannotApplyEquality, I don't think there should be an
BS> exception for comparison to null. The coder should use
BS> ReferenceEquals with one of the parameters null instead. Also, what
BS> are the semantics if the coded used Compare?

I agree and will check it, probably it is a bug.

BS> 8) BaseTypeRequired.BaseTypes should not return an array -- that
BS> approach is slow since C# creates and populates a new array eery
BS> time the property getter is used. It should probably return a
BS> readonly sorted list or dictionary.

Will check.

BS> 9) The Can/NotNull attributes should also be allowed on
BS> AttributeTargets.ReturnValue

We currently don't support attribute targets for annotations, so you just
need to annotate method or property.

BS> PS: Does RS implicitly know that event fields may be null, and that
BS> they shuld be copied to a local variable before being used to notify
BS> listeners?

No, because event field can be NotNull, if you initialize the event:


public event EventHandler SomethingChanged = delegate {};

BS> 10) It would be nice to have some async support. For a minimal
BS> example, ChangesMustBeInterlocked to indicate the entity can only be
BS> modified via the InterLocked support. Things beyond that simplicity
BS> are also great to have, but best left for RS 5.

I think you could record this in our issue tracker: http://jetbrains.net/jira/browse/RSRP

BS> 11) the attribute classes should be sealed

Indeed.

BS> 12) I think the "public BaseTypeRequiredAttribute ( Type baseTypes )"
constructor is redundant, as the same usage can be captured via the constructor
that uses "params Type[]". If I am right, maybe RS5 should include a check
for this issue?

Will check.

BS> Since the project I am working does not allow (via TeamFoundation check-in
policies)
BS> for properties that return an array, can you provide infomation as to
what other possible
BS> return types RS will support? Hopefully, something like IEnumerable]]>
should be safe at a minimum.

You mean, in the annotation attributes? I suppose the properties on attributes
are not used by ReSharper, so you can try to delete them and see if it works.
I will clarify this on monday with the team.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Illya, when your fixing the bugs, can you please ensure that any usages of
String.Format/StringBuilder.AppendFormat, and ToString all use a CultureInfo
if offered? The problem is that for projects that use the Globalization
FxCop rules, they're required to always supply those values and any code
that doesn't will fail.

Generally for non-UI facing code, the best option is
CultureInfo.InvariantCulture. That'll ensure that things are
parsed/stringified consistently across cultures.

Thanks!

"Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
news:76a2bd0b1565568ca767e6a4dde95@news.intellij.net...

Hello Brian,

>

BS> 1) The cref to String.Format generates an error:
BS> 2) The public members are undocumented and also generate errors if
BS> XML documentation is generated.

>

Will fix.

>

BS> 3) Can you provide some examples of using the Assertion and
BS> AssertionCondition attributes?

>


public static void
Assert( bool
condition, string message)

>

BS> 4) The casing and use of underscores in AssertionConditionType is
BS> contrary to MS guidelines. Can these spellings be corrected by a
BS> user without breaking RS? (I think so, but if so it would better for
BS> RS to also change your implementation). It also might be a good idea
BS> to add numeric related values (IsZero, IsNan, ...)

>

I will check, but I suppose user cannot change casing and still have
ReSharper understand the attributes. We will consider changing the casing.

>

BS> 5) TerminatesProgram is different from TerminatesThread. I could see
BS> a use for both.

>

This attribute means, that method never returns. For example:

>

if (a == null)
NeverReturns();
a.Do();

>

If NeverReturns is marked with attribute, warning about possible NRE will
not be issued.

>

BS> 6) Was CannotBeNull renamed to NotNull or is my memory foggy?

>

Previously we didn't force attribute names, you could set in options
whatever you want. Currently we allow only namespace to be changed, due to
some performance limitations and feature requirements.

>

BS> 7) For CannotApplyEquality, I don't think there should be an
BS> exception for comparison to null. The coder should use
BS> ReferenceEquals with one of the parameters null instead. Also, what
BS> are the semantics if the coded used Compare?

>

I agree and will check it, probably it is a bug.

>

BS> 8) BaseTypeRequired.BaseTypes should not return an array -- that
BS> approach is slow since C# creates and populates a new array eery
BS> time the property getter is used. It should probably return a
BS> readonly sorted list or dictionary.

>

Will check.

>

BS> 9) The Can/NotNull attributes should also be allowed on
BS> AttributeTargets.ReturnValue

>

We currently don't support attribute targets for annotations, so you just
need to annotate method or property.

>

BS> PS: Does RS implicitly know that event fields may be null, and that
BS> they shuld be copied to a local variable before being used to notify
BS> listeners?

>

No, because event field can be NotNull, if you initialize the event:

>


public event EventHandler SomethingChanged = delegate {};

>

BS> 10) It would be nice to have some async support. For a minimal
BS> example, ChangesMustBeInterlocked to indicate the entity can only be
BS> modified via the InterLocked support. Things beyond that simplicity
BS> are also great to have, but best left for RS 5.

>

I think you could record this in our issue tracker:
http://jetbrains.net/jira/browse/RSRP

>

BS> 11) the attribute classes should be sealed

>

Indeed.

>

BS> 12) I think the "public BaseTypeRequiredAttribute ( Type baseTypes )"
constructor is redundant, as the same usage can be captured via the
constructor that uses "params Type[]". If I am right, maybe RS5 should
include a check for this issue?

>

Will check.

>

BS> Since the project I am working does not allow (via TeamFoundation
check-in policies) BS> for properties that return an array, can you
provide infomation as to what other possible BS> return types RS will
support? Hopefully, something like IEnumerable<Type> should be safe at a
minimum.

>

You mean, in the annotation attributes? I suppose the properties on
attributes are not used by ReSharper, so you can try to delete them and
see if it works. I will clarify this on monday with the team.

>

Sincerely,
Ilya Ryzhenkov

>

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>


0
Comment actions Permalink

"So, there are no problems left, right?"

Not for me, as much as felt inclined to post as a Devil's Advocate. As long as we can drive this behaviour through R# configuration, I'm happy.

0
Comment actions Permalink

Hello Oren,

Could you please create an issue in the tracker? Thanks.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


ON> Illya, when your fixing the bugs, can you please ensure that any
ON> usages of String.Format/StringBuilder.AppendFormat, and ToString all
ON> use a CultureInfo if offered? The problem is that for projects that
ON> use the Globalization FxCop rules, they're required to always supply
ON> those values and any code that doesn't will fail.
ON>
ON> Generally for non-UI facing code, the best option is
ON> CultureInfo.InvariantCulture. That'll ensure that things are
ON> parsed/stringified consistently across cultures.
ON>
ON> Thanks!
ON>
ON> "Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
ON> news:76a2bd0b1565568ca767e6a4dde95@news.intellij.net...
ON>
>> Hello Brian,
>>
>> BS> 1) The cref to String.Format generates an error:
>> BS> 2) The public members are undocumented and also generate errors
>> if
>> BS> XML documentation is generated.
>> Will fix.
>>
>> BS> 3) Can you provide some examples of using the Assertion and BS>
>> AssertionCondition attributes?
>>
>>
>> public static void
>> Assert( bool
>> condition, string message)
>> BS> 4) The casing and use of underscores in AssertionConditionType is
>> BS> contrary to MS guidelines. Can these spellings be corrected by a
>> BS> user without breaking RS? (I think so, but if so it would better
>> for
>> BS> RS to also change your implementation). It also might be a good
>> idea
>> BS> to add numeric related values (IsZero, IsNan, ...)
>> I will check, but I suppose user cannot change casing and still have
>> ReSharper understand the attributes. We will consider changing the
>> casing.
>>
>> BS> 5) TerminatesProgram is different from TerminatesThread. I could
>> see BS> a use for both.
>>
>> This attribute means, that method never returns. For example:
>>
>> if (a == null)
>> NeverReturns();
>> a.Do();
>> If NeverReturns is marked with attribute, warning about possible NRE
>> will not be issued.
>>
>> BS> 6) Was CannotBeNull renamed to NotNull or is my memory foggy?
>>
>> Previously we didn't force attribute names, you could set in options
>> whatever you want. Currently we allow only namespace to be changed,
>> due to some performance limitations and feature requirements.
>>
>> BS> 7) For CannotApplyEquality, I don't think there should be an
>> BS> exception for comparison to null. The coder should use
>> BS> ReferenceEquals with one of the parameters null instead. Also,
>> what
>> BS> are the semantics if the coded used Compare?
>> I agree and will check it, probably it is a bug.
>>
>> BS> 8) BaseTypeRequired.BaseTypes should not return an array -- that
>> BS> approach is slow since C# creates and populates a new array eery
>> BS> time the property getter is used. It should probably return a BS>
>> readonly sorted list or dictionary.
>>
>> Will check.
>>
>> BS> 9) The Can/NotNull attributes should also be allowed on BS>
>> AttributeTargets.ReturnValue
>>
>> We currently don't support attribute targets for annotations, so you
>> just need to annotate method or property.
>>
>> BS> PS: Does RS implicitly know that event fields may be null, and
>> that BS> they shuld be copied to a local variable before being used
>> to notify BS> listeners?
>>
>> No, because event field can be NotNull, if you initialize the event:
>>
>>
>> public event EventHandler SomethingChanged = delegate {};
>> BS> 10) It would be nice to have some async support. For a minimal
>> BS> example, ChangesMustBeInterlocked to indicate the entity can only
>> be
>> BS> modified via the InterLocked support. Things beyond that
>> simplicity
>> BS> are also great to have, but best left for RS 5.
>> I think you could record this in our issue tracker:
>> http://jetbrains.net/jira/browse/RSRP
>>
>> BS> 11) the attribute classes should be sealed
>>
>> Indeed.
>>
>> BS> 12) I think the "public BaseTypeRequiredAttribute ( Type
>> baseTypes )" constructor is redundant, as the same usage can be
>> captured via the constructor that uses "params Type[]". If I am
>> right, maybe RS5 should include a check for this issue?
>>
>> Will check.
>>
>> BS> Since the project I am working does not allow (via TeamFoundation
>> check-in policies) BS> for properties that return an array, can you
>> provide infomation as to what other possible BS> return types RS will
>> support? Hopefully, something like IEnumerable should be safe >> at a minimum. >> >> You mean, in the annotation attributes? I suppose the properties on >> attributes are not used by ReSharper, so you can try to delete them >> and see if it works. I will clarify this on monday with the team. >> >> Sincerely, >> Ilya Ryzhenkov >> JetBrains, Inc >> http://www.jetbrains.com >>]]> "Develop with pleasure!"


0

Please sign in to leave a comment.