• RLB (unregistered)

    It wouldn't be the frist time someone was killed by a machine that shouldn't be able to kill.

  • Little Bobby Tables (unregistered)

    So TRWTF is that this code bomb lay dormant for many moons, unmolested, undetected and untriggered, until that strange combination of eldritch circumstances that enabled the machine to run, unaccountably, without error ...

  • CoderOfMassProduction (unregistered)

    Well, "\r\n" might be carriage-return/line-feed in C and C#, but it is "\r\n" in VB.

  • my name is missing (unregistered)

    Not much of a WTF, just a run of the mill null pointer exception. Maybe the world's code is now so good that there are no WTFs remaining?

  • bvs23bkv33 (unregistered)

    fifth!^M

  • fool (unregistered)

    Obviously the solution is to just wrap this in a catch and ignore all exceptions.

  • fool (unregistered)

    Or "On Error Resume Next", that's even better.

  • P (unregistered) in reply to Little Bobby Tables

    Yes, someone must have got round to fixing the machine itself after fixing the bugs in their software! On the other hand maybe the machine received a firmware update which made it return a null string when previously it returned something like "Hey, I'm OK!\r\n" :)

  • Zach (unregistered) in reply to P

    So let me guess, she had to fix the problem by adding in the line

    if (PerformSomeOperation(index) == null) PerformSomeOperation(index) = "Hey I'm Ok\r\n";

  • (nodebb)

    This is when a Try block is your friend.

  • Jay (unregistered) in reply to Zach

    more like:

    If IsNothing(PerformSomeOperation(index) Then PerformSomeOperation(index) = "Hey I'm Ok" & vbCrLf End If

    This will work if this is in the "PerformSomeOperation" method it's self.

    You could fix it from outside to at least not fail on replace in a null by doing this:

    Dim errorMsg As String = somePieceOfHardware.PerformSomeOperation(index) errorMsg = If(IsNothing(errorMsg), "", errorMsg.Replace("\r\n", vbCrLf))

    but, the method it's self should still be fixed so as to not produce null messages (possibly some better try-catch logic is needed).

  • (nodebb)

    Yeah, okay, so she didn't know that vbCrLf = “\r\n”. The story's a good warning to VB.Net programmers who might not have known that, but as far as WTF's go, it's not the worst. She probably thought she was avoiding potential problems by having a managed code way of doing new lines.

  • RichP (unregistered)

    Best guess as to where this came from: At some point in the past (maybe on a different project even) someone had to process input with just line feeds, and they needed to convert to vbCrLf. Later on, they changed the machine and eventually noticed they were getting "\r\n\n" in the output. They "fixed" it by changing the first parameter to the replace function.

  • VB Veteran (unregistered)

    It's easier than you would think to fix this:

    Dim errorMsg As String = (somePieceOfHardware.PerformSomeOperation(index) & "").Replace("\r\n", vbCrLf)

    ftfy.

  • jeepwran (unregistered) in reply to Jay

    With the latest language null check features and using IF(nullable, return):

    Dim errorMsg As String = If(somePieceOfHardware.PerformSomeOperation(index)?.Replace("\r\n", vbCrLf), "")

  • robby the robot (unregistered)

    Real WTF is software that returns an "error" code every time, whether it's successful or not.

  • (nodebb) in reply to robby the robot

    Sure! "Success" only is achieved if the software runs without error AND returns an error code. If it fails to return an error code, then it didn't successfully complete.

  • Brian Boorman (google) in reply to robby the robot

    I think that you're just referring to bad variable naming. Perhaps the machine always returned a status code which either said the operation was successful or what failed.

  • Carl Clawson (unregistered) in reply to CoderOfMassProduction

    Yessir, that is definitely the real WTF here.

  • Klimax (unregistered)

    Main WTF is already taken care of, so I nominate Remy as secondary. CRLF is perfectly valid and standard line termination sequence. (Actually UNIX was the one that was nonstandard and at that time WTF)

  • Adam (unregistered)

    Since this is VB.net \ isn't an escape character and "\r\n" does not equal vbCrLf. The equivalent line in C# is: Replace("\r\n", "\r\n").

  • (nodebb) in reply to VB Veteran

    This is a better solution for VB. The problem with IIF() is that the arguments are executed before the function is called, meaning you'll still get the NullReferenceException. The IF() looks like the VB version of C#'s ?? so that's acceptable as well. PerformSomeOperation() returning null on success isn't exactly a WTF. You just need something smarter to evaluate what it returns. I would say that's just basic defensive programming.

  • xtal256 (unregistered)

    "TRWTF is Windows having screwed up line endings"

    Windows didn't "screw up" line endings, you just have to understand the history of what carriage-return and line-feed did.

  • (nodebb)

    VB.Net is as powerful as C# but strings are different. "\r\n" in VB would be a literal "\r\n" or, in C#, the equivalent of @"\r\n" so the replace was actually doing the right thing. You do need a check for null reference, though, whether that be the new ?. sequence, an IF statement, or a simple "If Not String.IsNullOrEmpty" check.

  • . (unregistered)

    Windows is actually doing line endings right. With Linux style endings the cursor should just move down, not back to the start of the line though

  • Chris (unregistered)

    The proper C# way would be to replace with Environment.NewLine. For portability, in case you ever want to take your C# application to a different platform. Could happen, you never know.

  • Hasseman (unregistered) in reply to xtal256

    Indeed Carriage return was from typewriters : go back to start of line and line feed (new line) is move to next line and keep position /r/n is the sequence to move to beginning of next line. That other systems have re-defined \n to mean two things is another story

  • DCL (unregistered) in reply to my name is missing

    Doubtful, very doubtful. I'd go as far as saying virtually impossible.

  • RLB (unregistered) in reply to xtal256

    Didn't you hear?

    Linus invented computers, and anything Not Linusic does therefore Not Compute.

  • siciac (unregistered) in reply to Hasseman

    Not typewriters, but from terminals that were wired to printers. The reason for two characters was not that the printer needed to be instructed "perform a carriage return and then a newline" but that they couldn't do so fast enough to keep up with the data from the terminal.

  • jay (unregistered)

    As others have pointed out, "" is not an escape character in VB. "\r\n" is not a hex 0D0A, it's the four characters, "", "r", "", and "n". So the replace is not useless at all.

    I suspect that what happened here is that when they translated from C to VB, somebody didn't know that \r\n is not the same as carriage return / line feed, and ended lines with "\r\n", appending 4 characters to the end of the line. Someone else either didn't want to make the effort to fix the original problem, or didn't understand it, or didn't have access to that code, or something, and so put in this kludge fix.

    Yeah, the null pointer exception is a whole different issue.

  • jay (unregistered)

    Hmm, I don't know how to edit my previous post. Apparently "\" IS an escape character on this forum.

Leave a comment on “It Only Crashes When It Works”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article