Assert that we're about to do a no-op



  • Just found this:

                    Common.Debug.Assert(__UserProfile.UserId == _Id);
                    __UserProfile.UserId = _Id;

    Revision history shows that both lines were added at the same time. The mind boggles.


  • ♿ (Parody)

    @pjt33 said:

    Just found this:

                    Common.Debug.Assert(__UserProfile.UserId == _Id);
                    __UserProfile.UserId = _Id;

    Revision history shows that both lines were added at the same time. The mind boggles.

    What else happened in that commit (or recently after)? It looks the sort of thing that might happen when you know that it should be that way, but it isn't in some cases. So you put the assert in to try to find what's going on, and the assignment in to fix the non-debugging case where for some reason it isn't.

    Obviously, that just covers up the problem, but I know I've done some stupid things like that when rage-debugging.



  • @boomzilla said:

    I've done some stupid things
     

    I KNEW IT


  • ♿ (Parody)

    @dhromed said:

    @boomzilla said:
    I've done some stupid things

    I KNEW IT

    I'd say this was quoted out of context, but it turns out the context doesn't really matter.



  • @boomzilla said:

    @dhromed said:
    @boomzilla said:
    I've done some stupid things

    I KNEW IT

    I'd say this was quoted out of context, but it turns out the context doesn't really matter.

    Well I'd say that this is better than the current quote in dhromed's signature.



  • @boomzilla said:

    rage-debugging.

    What a bloody brilliant phrase that is.  Will shamelessly appropriate it ...

     



  • @pjt33 said:

                    Common.Debug.Assert(__UserProfile.UserId == _Id);
    __UserProfile.UserId = _Id;

    Well, in some languages, the assertion could be true while the object types differ... definitely a funny way to cast variables ;-)



  • @Ben L. said:

    Well I'd say that this is better than the current quote in dhromed's signature.
     

    I disagree. This one is like a wonderful snack that hits the spot, but is gone in seconds.

    My sig quote is more of a timeless, wholesome meal.



  • @boomzilla said:

    It looks the sort of thing that might happen when you know that it should be that way, but it isn't in some cases. So you put the assert in to try to find what's going on, and the assignment in to fix the non-debugging case where for some reason it isn't.

    Obviously, that just covers up the problem, but I know I've done some stupid things like that when rage-debugging.

    I think I've worked it out. The assertion currently never fails, but it covers up a complete lack of encapsulation which would make it very easy to break. The sane approach would have been to fix the encapsulation, but...


  • @DaveK said:

    @boomzilla said:

    rage-debugging.

    What a bloody brilliant phrase that is.  Will shamelessly appropriate it ...

     

    Did anyone else misread that as "rape-debugging"? I think morb's comfort women in "old bug" thread are getting to me...


  • Discourse touched me in a no-no place

    @lol_epicetou said:

    Well, in some languages, the assertion could be true while the object types differ...
    In some languages the assert could be doing something significant like assigning to some third party variable.


  • Considered Harmful

    @pjt33 said:

                    Common.Debug.Assert(__UserProfile.UserId == _Id);
    __UserProfile.UserId = _Id;

    .

    Maybe they want this to be an error if it somehow comes up in a debug build (so they can catch it) but in a release build they'd rather just "fix it" to match their expectations.</'p>



  • @Zemm said:

    @DaveK said:

    @boomzilla said:

    rage-debugging.

    What a bloody brilliant phrase that is.  Will shamelessly appropriate it ...

     

    Did anyone else misread that as "rape-debugging"? I think morb's comfort women in "old bug" thread are getting to me...

    That does it.  If that shit comes into this thread too, I'm rape-quitting.




  • @joe.edwards said:

    Maybe they want this to be an error if it somehow comes up in a debug build (so they can catch it) but in a release build they'd rather just "fix it" to match their expectations.


    Almost certainly. However, the scare quotes are certainly appropriate. If the user ID is wrong, why on Earth should any of the other data be correct?


Log in to reply