• Edd (unregistered)

    echo

  • (nodebb)

    We won't mention the TRWTF of the application's logs being just println to stdout, I guess...

  • (author) in reply to Steve_The_Cynic

    I suspect, in this case, they probably have real logging (I assume?) and they also redirect stdout to the logs. But it's a fair point that they might not even have that.

  • Tim Ward (unregistered)

    Once Upon A Time adding a printf was a desperate last resort for someone who didn't know how to debug, the last refuge of the incompetent.

    These days logging is regarded as good practice.

    Times change.

  • Michael (unregistered)

    FTFY: public int getBrillant(){ System.out.println("Brillant"); return 1; }

  • (nodebb)

    For code that "is not inteded to go to production" a tests should be written that FAILS as long as the code is present from the very beginning. This test gets added to the suite that is executed only before a prod (or whatever level) deployment can occur....

    FYI...

    “The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output. After I’d written the first xUnit framework in Smalltalk I remembered reading this and tried it out. That was the origin of TDD for me. When describing TDD to older programmers, I often hear, “Of course. How else could you program?” Therefore I refer to my role as ‘rediscovering’ TDD.”

    —Kent Beck, re-discoverer and namer of Test-Driven Development

    And don't forget Edsger W. Dijkstra in 1972......

  • my name is missing (unregistered)

    What gets me all the time is when no one actually looks at the log. You don't need a test to keep this out of logging if you actually looked at the log. I know people who only looked at a log when someone complained about a bug, only to find out the log was telling them about the bug for months. Then you have Target who bought a product to tell them they were hacked; they turned it on, it spammed the log screaming about hacking, so they turned it off. Months later they tried it again and it screamed again, then someone had the bright idea that maybe it was telling them something. Too late....

  • Brian (unregistered) in reply to Tim Ward
    Once Upon A Time adding a printf was a desperate last resort for someone who didn't know how to debug, the last refuge of the incompetent.

    Or when you're unable to debug a process in its natural environment, or when you're facing a Heisenbug where the mere act of debugging it prevents the bug from occurring, or when debugging is not practical such as wanting to examine values through many iterations of a loop, or when the problem occurs only intermittently, or when you're trying to quickly narrow down the location of the bug so you can figure out where to stick the breakpoints in the first place, or ...

    Of course, I'm assuming that when you say "debug" you mean "insert a breakpoint and step through the code" which is only one of many ways to identify bugs in a program. Logging is another, and far from being the "last refuge of the incompetent", in many cases it's the most efficient or even the only option.

  • man grep (unregistered)

    tail -F logfile | grep -v echo ... problem solved

  • Angela Anuszewski (google) in reply to Tim Ward

    Some of us work on systems that aren't allowed to use debuggers, ya know? :)

  • Angela Anuszewski (google) in reply to Tim Ward

    Some of us work on systems that aren't allowed to use debuggers, ya know? :)

  • ooOOooGa (unregistered) in reply to man grep

    sed -i '/^echo$/ d' logfile

  • (nodebb)

    At least it wasn't written in PHP, where that echo would be a needle in a haystack.

  • D-Coder (unregistered)

    I'm just wondering if they removed this... and how much broke when they did that.

  • Carl Witthoft (google)

    Ecce echo!

    or

    echolalalalalalia

  • (nodebb)

    OK relying on toString overrides to convert collections of objects to emails is the single stupidest thing I've heard in a while. This is exactly why adding toString to object was a huge mistake in both Java and C#. 🤦‍♂️🤦‍♂️🤦‍♂️

  • What's in a name? (unregistered)

    The name "getEcho" in a toString() call - truly a WTF. Was this meant to be a stand-in for a call to some sophisticated external process or library that is meant to convert the object to which this process holds reference to a string??? Was the int response meant to respond with success/some_error_code?? What could possibly have been going through their mind... On the plus side, you have a way of counting how many times toString has been called... I'm inclined to agree with Tim Ward on this one, since I suspect this is more of an event-driven system and once you resort to print statements in that case, you're already in way over your head.

  • Chris (unregistered)

    The WTF for me - not the biggest, but the one that irritates me most - is the integer return, that is set to only ever return 1. It shows the programmer is a relic just like the programming style they keep applying over and over again without a single brainwave flittering through their skull, considering what could actually happen in their code, and the best way to communicate any possible errors. That integer return will never contain any useful information. I'm actually worried about the programmer who wrote this. Maybe they died internally a long time ago. Somebody should check on them.

  • (nodebb) in reply to Mr. TA

    toString is plenty useful to allow quick data investigation. People using an interface wrong can be blamed on the interface design, yes, but only up to a certain point. Nobody prevents people from writing a Unix emulator, where "touch" deletes files.

  • (nodebb)

    https://youtu.be/oWR7Ib48M8g

  • Neveranulll (unregistered) in reply to Brian

    Yes!!

  • (nodebb) in reply to R3D3

    I know, I do it myself, however a specialized method would've been badly preferable. Imagine a protected ToDebugString virtual method which can only be called by the debugger, and ideally not callable from code directly, as in a special compile error.

    Addendum 2021-07-03 15:30: Vastly not badly

  • Mike Rosoft (unregistered)

    ToString() serves to present the data to the user. This allows data binding; the user interface framework (like Windows Forms or WPF) cannot make any assumptions about what type is the field which is being displayed to the user.

  • Tim (unregistered) in reply to Steve_The_Cynic

    https://12factor.net/logs

  • Hob (unregistered)

    I remember spending a long day debugging an issue which later turned out to be related to overloaded toString:

    A class in a project I worked on was responsible for fetching a large buffer of bytes. Like, tens of megabytes large. It had this getBuffer method, which did a peculiar thing: it assumed that ownership of the buffer is passed to the caller, and it nulled its internal reference to it. It also had toString overloaded, which did a terrible thing: called getBuffer, and stringified its X initial bytes. So basically, toString mutated, and invalidated, the object.

    Fun things started happening (if you count NPEs as fun) when logging level was changed to verbose, or when a dev stepped through the application in debugger. NPEs appeared randomly, and depended on the fact whether the byte-holder object was written to logs, or whether you had it added to Watch window, or hovered your mouse over it while debugging.

    It was a fun day.

Leave a comment on “Echo echo echo echo”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article