• (cs) 

    PRIVATE FUNCTION IsNothing(Obj)
      IF Obj Is Nothing THEN
        IsNothing = TRUE
      ELSE
        IsNothing = FALSE
      END IF
    END FUNCTION



    I never get tired of these.
  • boohiss (unregistered)

    Oh if only it was as easy as typing "// handle errors". How much easier would my life be?

  • Masklinn (unregistered) 
    .plabel
{
    white-space: nowrap;
}

    a wrapping CSS class that doesn't wrap, and a non wrapping one that wraps !

    Pure genius !

    As a side note, i think that the last one had already been posted here

  • (cs) in reply to Masklinn

    "Brillant!"[;)]

  • Synonymous Coward (unregistered)
    Alex Papadimoulis:

    And finally we have Shane Courtrille, who demonstrates that higly-paid consultants do actually provide value. Note how much easier this is to use than typing "(myObject Is Nothing)" ... 

    PRIVATE FUNCTION IsNothing(Obj)
      IF Obj Is Nothing THEN
        IsNothing = TRUE
  ELSE
    IsNothing = FALSE
      END IF
    END FUNCTION


    This isn't necessarily superfluous. Can't you call a function by reference in VB?
  • Matt (unregistered)
    Alex Papadimoulis:

    Then there's Andy Korth who couldn't quite figure out what was so important with June 7th ... 

    If CDate(BeginDate) = CDate("6/7/1") Then
    BeginDate = BeginDate
End If


    Obviously because it was my son's second birthday.  Duh!
  • frank rizzo (unregistered) in reply to boohiss

    Ah, the empty catch block...the C# version of VB's On Error Resume Next...

  • (cs)
    Alex Papadimoulis:
    Christopher Sawyer is fortunate to work with a pretty extensive transaction monitoring system. It does all sorts of things from live charting to predictive analysis. Like anything else, it does have a few weak points ... one being the difficulty in determing whether a transaction was successful or not ....

    [image]


    Maybe Status == Success means it successfully failed...
  • (cs)

    <FONT face="Courier New" size=2>i've actually seen a 53 line java switch statement along those lines back in college (i call it the 'corpulent' toInt method).  it was a junior-level class, however, so it was just kind of sad and pathetic.  i didn't feel like explaining basic concepts, so i just commented out the switch and replaced with the one-liner and a comment that was like: // <initals>: we fixed the glitch!  i really wish i could remember what his default case was.  i think it was just to return the value that A or Z was supposed to have.</FONT>

  • (cs) in reply to boohiss
    Anonymous:
    Oh if only it was as easy as typing "// handle errors". How much easier would my life be?


    Possibly negatively so.

    Your Manager: Mr. Anonymous, we have a program that can do what you do, so we no longer require your services.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Ytram
    Ytram:

    PRIVATE FUNCTION IsNothing(Obj)
      IF Obj Is Nothing THEN
        IsNothing = TRUE
      ELSE
        IsNothing = FALSE
      END IF
    END FUNCTION




    I never get tired of these.

    <FONT face="Courier New" size=2>encapsulation: it's not just for ravers anymore.  [<:o)]</FONT>

  • (cs)
    Alex Papadimoulis:
    Yes, that's right, I wrote "Vari-Post 2000."

    Should you really have a hyphen when using bicapitalisation?

    First up is a submission from Andrew Vos. I generally do my best to conceal the author of code posted here, but our submitter did take blame for this snippet. Note that he actually make it all the way to "Z" before shaking his, saying "WTF!", and starting over ... 

    Private Function GetLetter(ByVal Index As Integer) As String 
      Select Case Index 
        Case 0 Return "a" 
        Case 1 Return "b" 
        'SNIP: ... all the way to "Z"
  End Select 
    End Function


    If you are concerned about different character sets and wish a general solution, this would be the way to go.

    Christopher Sawyer is fortunate to work with a pretty extensive transaction monitoring system. It does all sorts of things from live charting to predictive analysis. Like anything else, it does have a few weak points ... one being the difficulty in determing whether a transaction was successful or not ....

    [image]


    Obviously, the answer is both!

    Sincerely,

    Gene Wirchenko

  • (cs)
    Alex Papadimoulis:

    Then there's Andy Korth who couldn't quite figure out what was so important with June 7th ... 

    If CDate(BeginDate) = CDate("6/7/1") Then
    BeginDate = BeginDate
End If


    It's probably debugging code that didn't get removed.  I've done this kind of thing before, you notice that something goes wrong in the middle of a long loop when you hit a certain value and need a statement on which to set a breakpoint.
  • (cs) in reply to Scott B.
    Scott B.:
    Alex Papadimoulis:

    Then there's Andy Korth who couldn't quite figure out what was so important with June 7th ... 

    If CDate(BeginDate) = CDate("6/7/1") Then
    BeginDate = BeginDate
End If



    It's probably debugging code that didn't get removed.  I've done this kind of thing before, you notice that something goes wrong in the middle of a long loop when you hit a certain value and need a statement on which to set a breakpoint.

    Don't debuggers usually have conditional breakpoints?

  • (cs) in reply to Scott B.

    How is BeginDate = BeginDate going to set a breakpoint?

  • (cs) in reply to Richard Nixon
    Richard Nixon:
    How is BeginDate = BeginDate going to set a breakpoint?


    I think he's referring to placing a breakpoint inside of a conditional statement that coincides with when he wants to break.

    A simplistic example would be

    if(debugCondition)
    {
        // you could put a breakpoint here so that it breaks only when the debug condition is met
        DoSomething(); 
    }

    It would be easier than placing a breakpoint on something that gets hit everytime.  As far as conditional breakpoints, I've never seen them in Visual Studio .NET, but I wouldn't be surprised if they exist.  Other IDEs I would have no clue about.
  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    Christopher Sawyer is fortunate to work with a pretty extensive transaction monitoring system. It does all sorts of things from live charting to predictive analysis. Like anything else, it does have a few weak points ... one being the difficulty in determing whether a transaction was successful or not ....

    [image]


    Obviously, the answer is both!

    Sincerely,

    Gene Wirchenko



    Only if you put it in a box and don't look at it.
  • Tom (unregistered) in reply to dubwai

    Yes, but I usually slap 

    a=1
    in there and tell it to break on that line, then step through the rest of the code with an immediate window open.

  • (cs) in reply to John Smallberries
    John Smallberries:
    Alex Papadimoulis:
    Christopher Sawyer is fortunate to work with a pretty extensive transaction monitoring system. It does all sorts of things from live charting to predictive analysis. Like anything else, it does have a few weak points ... one being the difficulty in determing whether a transaction was successful or not ....

    [image]


    Maybe Status == Success means it successfully failed...

    No, no, no.  Of course the value of "Status" tells you where to go to find out if it was successful.  It's the column name!
    (java usage supplied)
    String where = rs.getString("Status");
    //where = "Success"
    String successOrFail = rs.getString(where);
  • (cs) in reply to dubwai
    dubwai:

    Don't debuggers usually have conditional breakpoints?



    Sure, and usually they can't evaluate much more than built-in types, or have interfaces that are harder to use than typing 3 lines of code.
  • Benoit (unregistered) in reply to Ytram

    I do that from time to time and I even checked one in so I could be the other of this WTF.  And the reason is to avoid conditional breakpoints.  Conditional breakpoints really slows down the program so recompiling with the condition in the code can be faster.

  • (cs) in reply to Ytram
    Ytram:
    Richard Nixon:
    How is BeginDate = BeginDate going to set a breakpoint?


    I think he's referring to placing a breakpoint inside of a conditional statement that coincides with when he wants to break.

    A simplistic example would be

    if(debugCondition)
    {
        // you could put a breakpoint here so that it breaks only when the debug condition is met
        DoSomething(); 
    }

    It would be easier than placing a breakpoint on something that gets hit everytime.  As far as conditional breakpoints, I've never seen them in Visual Studio .NET, but I wouldn't be surprised if they exist.  Other IDEs I would have no clue about.


    Ah, I see. Thanks for clearing that up for me.
  • Daveh (unregistered)

    Visual Studio v6 has conditional breakpoints so I assume VS .NET has them too. They are not particularily easy to us in v6 however, and its generally faster just to add an if block and set the breakpoint inside it.

  • Benoit (unregistered) in reply to Benoit
    Anonymous:
    I do that from time to time and I even checked one in so I could be the author of this WTF.
  • Oliver Klozoff (unregistered) in reply to Scott B.

    Furthermore, anyone who's ever used a conditional breakpoint knows that they slow down the program tremendously, because what happens behind the scenes is this:

    1. Debugger sets breakpoint
    2. Debugger runs program and waits for breakpoint
    3. Debugger tests for condition
    4. If condition is NOT present, go to step 2.

    If the particular code in question happens to be in a loop where it'll be passed by a few hundred thousand times before getting to the value in question (usually the point where it breaks), using a conditional breakpoint can mean waiting several minutes instead of several seconds.

  • Oliver Klozoff (unregistered) in reply to Oliver Klozoff

    Gah. Who wrote this forum software? Don't they know that the point of a PREVIEW is to, well, take a look at what your post is going to look like when it's posted?

  • David (unregistered) in reply to emptyset
    emptyset:
    Ytram:

    PRIVATE FUNCTION IsNothing(Obj)
      IF Obj Is Nothing THEN
        IsNothing = TRUE
      ELSE
        IsNothing = FALSE
      END IF
    END FUNCTION




    I never get tired of these.

    <FONT face="Courier New" size=2>encapsulation: it's not just for ravers anymore.  [<:o)]</FONT>

     

    Well of course!  What happens if MS decides to change the implementation of the Is Nothing command?  You wouldn't want to have to go back through all your code and change it, would you?

  • Baron (unregistered) in reply to John Smallberries
    John Smallberries:
    Alex Papadimoulis:
    Christopher Sawyer is fortunate to work with a pretty extensive transaction monitoring system. It does all sorts of things from live charting to predictive analysis. Like anything else, it does have a few weak points ... one being the difficulty in determing whether a transaction was successful or not ....

    [image]


    Maybe Status == Success means it successfully failed...


    The unix man page for the 'false' command simply says " false - do nothing, unsuccessfully" and 'true' says "true - do nothing, successfully"  which are both pretty hilarious.  Of course, my real favorite is the message you get when you type "%blow" at a bash prompt.
  • (cs)
    Alex Papadimoulis:
    try
{
    System.Web.Mail.SmtpMail.Send(myMail);
} catch {
    // handle errors
}

    This is the biggest, most common WTF ever.  I hate when people do this.

  • PhoenixPo (unregistered)
    Alex Papadimoulis:

    Then there's Andy Korth who couldn't quite figure out what was so important with June 7th ... 

    If CDate(BeginDate) = CDate("6/7/1") Then
    BeginDate = BeginDate
End If


    Instead of setting a conditional break point, the programmer typed this statement and set the break point within the IF statement.  That way, the debugger will stop at that point only when the value is equal to the one specified within the IF statement.
    I used to do that when I was new, and still do that when I'm in a hurry or trying to prove a point to someone.
    
            
    
        
    • 
        
  • 
 Suomynona   (unregistered)                                         in reply to Ytram
            
            
    
                
     Ytram:
    It would be easier than placing a breakpoint on something that gets hit
everytime.  As far as conditional breakpoints, I've never seen
them in Visual Studio .NET, but I wouldn't be surprised if they
exist.  Other IDEs I would have no clue about.

    

    
VS.NET 2003: Open Breakpoints window, select breakpoint, click on "Properties", click on "Condition", et voilà.
    

    
VS.NET 2005 Beta 2: Right-click on breakpoint marker, select "Condition".
    

    
            
    
        
    • 
        
  • 
    (cs)                                     
            
    
                
    .plabel
    {
        PADDING-RIGHT: 5px;
        PADDING-LEFT: 5px;
        PADDING-BOTTOM: 0px;
        COLOR: black;
        PADDING-TOP: 3px;
        TEXT-ALIGN: left;
        white-space: nowrap;
    }

    .plabelnowrap
    {
        PADDING-RIGHT: 5px;
        PADDING-LEFT: 5px;
        PADDING-BOTTOM: 0px;
        COLOR: black;
        PADDING-TOP: 3px;
        TEXT-ALIGN: left;
    }


    Which is why you NEVER EVER give CSS classes names that indicate their style.
    Well, part of the reason, anyway.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to John Smallberries
            
            
    
                
     Alex Papadimoulis:
    Christopher Sawyer is fortunate to work with a pretty extensive transaction monitoring system. It does all sorts of things from live charting to predictive analysis. Like anything else, it does have a few weak points ... one being the difficulty in determing whether a transaction was successful or not .... 

    [image] 

    Maybe successful steps, failed transaction?  Un-normalized data?  Or maybe it's just software for "Opposite Bank Inc."
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Oliver Klozoff
            
            
    
                
     Anonymous:
    Furthermore, anyone who's ever used a conditional breakpoint knows that they slow down the program tremendously, because what happens behind the scenes is this: 

      

    1. Debugger sets breakpoint 

    2. Debugger runs program and waits for breakpoint 

    3. Debugger tests for condition 

    4. If condition is NOT present, go to step 2. 
    

    If the particular code in question happens to be in a loop where it'll be passed by a few hundred thousand times before getting to the value in question (usually the point where it breaks), using a conditional breakpoint can mean waiting several minutes instead of several seconds.
    

    I guess.  I don't really use debuggers much.  To me they are just a waste of time.  I've also had too many experiences where the debugger changes how the code executes.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to dubwai
            
            
    
                
     dubwai:
    I guess.  I don't really use debuggers
much.  To me they are just a waste of time.  I've also had
too many experiences where the debugger changes how the code executes.

    

    
I use a debugger (Eclipse) all the time and have never had this
happen.  Plus, hot swap of deployed code is a huge time saver.
    
            
    
        
    • 
        
  • 
    (cs)                                     
            
    
                
    .plabel
    {
        PADDING-RIGHT: 5px;
        PADDING-LEFT: 5px;
        PADDING-BOTTOM: 0px;
        COLOR: black;
        PADDING-TOP: 3px;
        TEXT-ALIGN: left;
        white-space: nowrap;
    }

    .plabelnowrap
    {
        PADDING-RIGHT: 5px;
        PADDING-LEFT: 5px;
        PADDING-BOTTOM: 0px;
        COLOR: black;
        PADDING-TOP: 3px;
        TEXT-ALIGN: left;
    }

    Aw geez.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Mung Kee
            
            
    
                
     Mung Kee:
     dubwai:
    

    I guess.  I don't really use debuggers much.  To me they are just a waste of time.  I've also had too many experiences where the debugger changes how the code executes.
    



    I use a debugger (Eclipse) all the time and have never had this happen.  Plus, hot swap of deployed code is a huge time saver.
    

    I had a co-worker arguing with me about the value of debuggers once.  Then he came to me and told me my code wasn't working.  After about 30 minutes for me and hours for him we determined the debugger was causing the problem.
    

    Personally, I prefer good logging.  Debuggers are almost useless with multithreading bugs and don't help with production issues.  If the logging doesn't give enough info to solve the problem, then the logging needs to be improved anyway.  Debuggers encourage laziness.  The only time I use them is when I'm having a brain-fart and need a sanity check.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to dubwai
            
            
    
                
     dubwai:
    Debuggers encourage laziness.


    So do text editors.  Real programmers use cat.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Maurits
            
            
    
                
     Maurits:
     dubwai:
    Debuggers encourage laziness.


    So do text editors.  Real programmers use cat.
    

    I never suggested 'real programmers' don't use debuggers.  I just personally find that I can solve more problems faster with good log/debug statements.  I used to use debuggers a lot but I don't even think about it anymore.  I any event, when the code is running in production, I don't have the option of opening up a debugger anyway.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to dubwai
            
            
    
                
     dubwai:
     Maurits:
     dubwai:
    Debuggers encourage laziness.


    So do text editors.  Real programmers use cat.
    

    I never suggested 'real programmers' don't use debuggers.  I
just personally find that I can solve more problems faster with good
log/debug statements.  I used to use debuggers a lot but I don't
even think about it anymore.  I any event, when the code is
running in production, I don't have the option of opening up a debugger
anyway.

    

    
Who says you can't have both?
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Mung Kee
            
            
    
                
     Mung Kee:
     dubwai:
     Maurits:
     dubwai:
    Debuggers encourage laziness.


    So do text editors.  Real programmers use cat.
    

    I never suggested 'real programmers' don't use debuggers.  I
just personally find that I can solve more problems faster with good
log/debug statements.  I used to use debuggers a lot but I don't
even think about it anymore.  I any event, when the code is
running in production, I don't have the option of opening up a debugger
anyway.

    

    
Who says you can't have both?

    
I'm just not a fan of continually bouncing an app server for trivial code changes.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Mung Kee
            
            
    
                
     Mung Kee:
     Mung Kee:
     dubwai:
    

     Maurits:
     dubwai:
    Debuggers encourage laziness.


    So do text editors.  Real programmers use cat.
    

    I never suggested 'real programmers' don't use debuggers.  I just personally find that I can solve more problems faster with good log/debug statements.  I used to use debuggers a lot but I don't even think about it anymore.  I any event, when the code is running in production, I don't have the option of opening up a debugger anyway.
    



    Who says you can't have both?

    I'm just not a fan of continually bouncing an app server for trivial code changes.
    

    You just mentioned hot-swapping.  Generally, I would try to debug on my desktop if at all possible.  What I've found is that developers that use debuggers tend to put substantially less debug statements and comments in their code than those who don't.  It's purely anecdotal but I think there's a reasonable causality there.
    

    One question, though, are you suggesting that you run a debugger on code in the app server?
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to dubwai
            
            
    
                
    What I've found is that developers that use
debuggers tend to put substantially less debug statements and comments
in their code than those who don't.
    
This is definitely true, but I'm not
one them.  I have a habit of writing substantial comments and
logging everything.  Many of my colleagues don't have such habits. <o:p></o:p>
    

    One question, though, are you suggesting that you run a debugger on code in the app server?
    
Not just suggesting...declaring.
    

    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to dubwai
            
            
    
                
     dubwai:
    Personally, I prefer good logging.  Debuggers
are almost useless with multithreading bugs and don't help with
production issues.  If the logging doesn't give enough info to
solve the problem, then the logging needs to be improved anyway. 
Debuggers encourage laziness.  The only time I use them is when
I'm having a brain-fart and need a sanity check.

    

    
I really can't fathom that point of view. Admittedly, if post-mortem
analysis of bugs (in a production environment, or with
hard-to-reproduce bugs) is required, logging is the only way. But in
any other case, a debugger IMO speeds up debugging by a factor of at
least 5 even if you have good logging. As for debuggers changing how
the code is executed - logging statements inserted while hunting a bug
do the same thing.
    
            
    
        
    • 
        
  • 
 Billy Conn   (unregistered)                                         in reply to JohnO
            
            
    
                
     JohnO:
     Alex Papadimoulis:
    

    try
{
    System.Web.Mail.SmtpMail.Send(myMail);
} catch {
        // handle errors
}
    

    

    This is the biggest, most common WTF ever.  I hate when people do this.

    

    
Question, then.  If I want to attempt to call a function, but
don't care if it throws an exception and fails, how SHOULD I do
it?  Admittedly, I'd prefer to see some logging done inside the
catch statement, but I have code that looks almost exactly like that:
it attempts to send out an email to our server team if certain errors
are thrown.  However, I don't really care if the email isn't sent,
and I don't want to propogate the email exception upwards, as I'm
already attempting to recover from another, more important type of
error, and I don't have much to do if the "I'm broke" email doesn't get
sent, other than what I was going to do in the first place.
    

    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Billy Conn
            
            
    
                
     Anonymous:
    Question, then.  If I want to attempt to call a function, but
don't care if it throws an exception and fails, how SHOULD I do
it?


    Easy... don't call the function at all.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Mung Kee
            
            
    
                
     Mung Kee:
     John Smallberries:
     Alex Papadimoulis:
    Christopher Sawyer is fortunate
to work with a pretty extensive transaction monitoring system. It does
all sorts of things from live charting to predictive analysis. Like
anything else, it does have a few weak points ... one being the
difficulty in determing whether a transaction was successful or not
.... 
    [image] 


    
Maybe Status == Success means it successfully failed...

    
No, no, no.  Of course the value of "Status" tells you where to go
to find out if it was successful.  It's the column name!
    
(java usage supplied)
    
String where = rs.getString("Status");
    
//where = "Success"
    
String successOrFail = rs.getString(where);

    
Ahh...indirection. Very clever.
    
Too bad they couldn't abstract it so that a failure was reported as successful.
    

    
I have a confession to make: I work at the same company as the poster of this WTF.
    
In fact, it was my predecessor who coded this gem. I guess I have to fix it....but how?
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Maurits
            
            
    
                
     Maurits:
     Anonymous:
    Question, then.  If I want to attempt to call a function, but
don't care if it throws an exception and fails, how SHOULD I do
it?


    Easy... don't call the function at all.

    
LOL! Great response, Maurits.
    

    
The real answer is, of course, simply call it. Don't wrap it in try/catch at all.
    
When an exception is thrown, the stack is unwound until an appropriate catch block is found. 
    
If one is never found, the app just crashes. So maybe "you" don't care
if it fails, but hopefully somewhere up the line, somebody does.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Ken Nipper
            
            
    
                
    --quote--
    

    "Brillant!"
    

    --/quote--
    

    That was my line lol [:D]
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Mung Kee
            
            
    
                
     Mung Kee:
    What I've found is that developers that use
debuggers tend to put substantially less debug statements and comments
in their code than those who don't.
    
This is definitely true, but I'm not
one them.  I have a habit of writing substantial comments and
logging everything.  Many of my colleagues don't have such habits. <o:p></o:p>
    

    One question, though, are you suggesting that you run a debugger on code in the app server?
    
Not just suggesting...declaring.
    


    

    
You should note that running in a debug mode on a production server is
a HUGE waste of resources.  All sorts of code checks and debug
methods are ADDED by whatever IDE you are using.  If you are
running debug modes on production clients you should be shot. 
Debuggers are for development purposes, not production bug
tracking.  Logging exists to help identify problems on production
apps.  
    

    
Now, logging is not meant to log every activity on
production; that is why plug-ins such as Apache's log4j have different
levels of logging.  You have debug logging for development issues,
then info/warn/error logging for production and live state
tracking.  Logging in production is supposed to give a general
idea of the flow/state of production app and give as much clue as
possible as where problems are arising.  I am not talking about
logging things that are used for business purposes of course, such as
credit card transaction logging.  
    

    

    
            
    
        
    • 
    


            


            
  • 



            


                

                
Leave a comment on “Vari-Post 2000”


                
Log In or post as a guest


                
                
Replying to comment #:


                

                    
                    Log Out
                


                

                    
                


                





                

                    
                


            


            
« Return to Article