17

I'm using belt and suspenders type checking for potential null object problems. Resharper isn't playing nicely though. In a debug build it marks the if (button != null) check as always true and puts a warning marker in the sidebar. In a release build it shades the Debug.Assert as never used code, although at least it's smart enough not to clutter the sidebar this time.

I don't want to disable the always true/false resharper warning globally because it can indicate a problem in the code. At the same time having to clutter my code up with ReSharper disable/restore ConditionIsAlwaysTrueOrFalse comments every time I do a check is ugly.

Is there an option somewhere in ReSharper 5.1 to disable build type contingent behavior so that the if isn't marked in debug builds, without preventing the warning from being shown if an Assert isn't present?

//This should always work unless the columns are fiddled with.
LinkButton button = e.Row.Cells[5].FindControl( "linkButtonName" ) as LinkButton;

//if this isn't the case in a debug build have VS throw an error in the devs face
Debug.Assert(button != null);

//Don't let anything go boom in production if an error isn't caught in dev
if (button != null)
    button.Visible = ( schedule.CreatedBy == Authentification.GetLoggedInUser() );
Dan Is Fiddling By Firelight
  • 5,981
  • 17
  • 77
  • 128
  • Since you assert, button being null is a "never happen" error, correct? Silently swallowing those in release is completely suicidal. You WANT them to go boom! – Stu Nov 17 '11 at 17:52
  • @stu I limited my sample code to what was needed to demonstrate the resharper issue. Logging code wasn't needed to show it. – Dan Is Fiddling By Firelight Nov 17 '11 at 19:01
  • My point is that "Don't let anything go boom in production if an error isn't caught in dev" is a spectacularly bad idea. – Stu Nov 17 '11 at 19:41
  • 1
    I raised the issue on JetBrain's support forum hoping to either have an expert point out a deeply hidden feature or someone from dev/support acknowledge it as being a problem; but after 5 days it hasn't gotten a response. http://devnet.jetbrains.net/message/5442138 – Dan Is Fiddling By Firelight Nov 22 '11 at 16:19
  • 2
    Looks to me like if you are saying `Debug.Assert(button != null)`, the following `if` condition need not even be present - The moment you write the Debug.Assert line, it means that you do not ever EVERexpect button to be null. If it is, then it is RIGHT that the App should bomb. – Zasz Nov 23 '11 at 18:06
  • Thank you Zasz, that's what I meant, only expressed much better. – Stu Dec 05 '11 at 20:03

2 Answers2

2

Not sure I agree with the design, but given what you want to accomplish try the following.

  1. Install Code Contracts from http://research.microsoft.com/en-us/projects/contracts/
  2. Rewrite your Debug.Asserts to Contract.Assert
  3. Then change your project properties to only check contracts in the debug build.

So it seems your problem is most easily solved by replacing debug.assert with the following:

  //Throw an error only if there is a problem with 
  Contract.Assert(button!=null);

However, I would probably change the design to make the work being done with the link button a method to the following assuming you may have other stuff going on with the link button.

So your code above would be:

    public void MyMethod(EventArgs e)
    {

            var button = e.Row.Cells[5].FindControl("linkButtonName") as LinkButton;
            SetButtonVisibility(button);
    }

    public void SetButtonVisibility(LinkButton button)
    {
        //The button is never null so its a contract
        Contract.Requires<ArgumentNullException>(button != null);

        button.Visible = (schedule.CreatedBy == Authentification.GetLoggedInUser());

    }

Hope that helps.

CTierney
  • 61
  • 4
0

You can try using Debug.Fail() instead:

if (button != null)
    button.Visible = ( schedule.CreatedBy == Authentification.GetLoggedInUser() );
else
    Debug.Fail("Button was not found");
splintor
  • 9,924
  • 6
  • 74
  • 89