• MiserableOldGit (unregistered)

    Frist comment blindly swallowed, so I've no idea what it was.

  • Lothar (unregistered)

    non-usage-warnings are useful so you don't want to deactivate them and some exceptions can be ignored so without context it's hard to say if this particular line is actually a WTF or not. Before Java added annotations that allow to deactivate a particular warning at a particular place in the code (here you would add a @SuppressWarning("unused")) I've solved these kind of warning in a quite similar way (just used if (e != e) {} instead) which might be another reason why I don't see this as a "full WTF" ;-)

  • RLB (unregistered) in reply to Lothar

    It's hard to say if this particular line is a WTF. But if similar (or even identical) lines occur all over the code, that's definitely a WTF.

  • (nodebb) in reply to Lothar

    Any one exception that you ignore is possibly OK, although blindly ignoring them is rarely a good idea. At least understand why the exception doesn't merit any special handling, and put a comment to explain why.

    If it's a recurring pattern that developer X just puts these in out of blind habit, malfeasance, indifference, or whatever, then it's a high-tier WTF, well worth visiting the chap (or chapette) with a top tier clue bat - probably in shape, size and manner of operation similar to a GAU-8 - in your back pocket in case of need.(1)

    Especially if Developers Y, Z, and W just blindly follow the pattern set up by X.

    (1) Y'all do keep a GUA-8 in your back pocket for emergencies, right?

  • WTFGuy (unregistered)

    About the only nice thing we can say about the 2 lines of code is:

    1. They braced & indented correctly. // @PRAGMA flamesuit = on
    2. They caught (and ignored) a ZendException rather than the fully generic Exception class. Although a ZendException is still the catchall type of the Zend framework and depending on the larger context there may be little practical difference between the two.

    As Steve said, it's the do it everywhere for no understood reason feature that elevates the whole codebase to a stenching WTF. And the whole staff to bovine idjits.

    As to Lothar's good point, this is another way in which "self-documenting code" isn't. If you need something like that de facto no-op to fool the linter, then it needs a comment like:
    // this is a deliberate no-op to fool the linter into thinking $e is not an unused variable

    And as well the catch block needs documentation as to why it's OK to swallow these specific type(s) of exceptions here and which logical failure conditions you are expecting to swallow. If you can't show "proof of work" for the intellectual rigor behind your decision, your code can safely be removed as random and thoughtless. Along with removing you from your job as random and thoughtless. When you (any you, including me) do code-smell crap like this you really need to thoroughly justify your decisions to the future maintenance dev, even if that somebody is you.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    In C and C++, the way to tell the compiler or a linter to ignore an unused variable is to cast it to void (or in the case of exception handlers and function parameters, you can omit the variable name and write only its type in the declaration).

    PHP intentionally doesn't have this feature, and according to that feature request, the convention for unused variables is to name them $_ and configure your linter to ignore that. (Without more details it's obviously unknown if the submitter's linter supports that feature.)

    But as the previous commenters said, TRWTF isn't so much the way that the warning is being ignored but that fact that the exception is being swallowed aimlessly by know-nothing cargo cult programmers.

  • (nodebb)

    Whenever my credit card comes back with insufficient funds, I just silently walk away from the cashier.

  • (nodebb)

    TRWTF is PHP for not having a warning for useless self assignment.

  • gnasher729 (unregistered)

    Xcode has some interesting warning behaviour. Say you have code “if (condition) statement;” and for debugging you don’t want this statement to be executed with minimal changes: if (false && condition) gives you a warning about dead code. So you write “if ((false) && condition)”. The parantheses tell the compiler “yes, I mean it”. The code is still optimised away but no warning.

  • Sole Purpose Of Visit (unregistered) in reply to gnasher729

    I would have thought (and I've given it caffeine-free, minimal thought) that a short-circuit operator ('&' rather than '&&') would negate the implicit requirement for parentheses and the resultant non-obvious compiler behaviour.

    But then again I need more coffee and a modicum of thought.

  • Sole Purpose Of Visit (unregistered) in reply to Mr. TA

    Inherited from C, although lint in it's many-splendored varieties will warn you. Perhaps.

    One of the little-observed problems with PHP is that it was built on top of the assumption that C semantics were the way to go. Which was actually not unreasonable at the time.

    Unfortunately PHP then accreted various conflict resolutions between C semantics (as here) and object semantics (as per the === operator). It's a mess, but it's understandable how it got there.

  • Anonymous (unregistered)

    At least they enforce the linter rules. I've worked on software that had 10,000 warnings in 20,000 lines of code... anything is preferable to that, even $e = $e.

  • (nodebb) in reply to Anonymous') OR 1=1; DROP TABLE wtf; --

    PHP intentionally doesn't have this feature

    However, PHP just added (November 2020) the ability to catch without declaring a local to hold the exception reference... which is the correct pattern to use in this situation. So kudos to them for at least addressing the problem head on and not giving in to pressure to introduce a work around that might do more harm than good.

  • Sole Purpose Of Visit (unregistered) in reply to Anonymous

    You'd kinda hafta qualify what "linter rules" are. I started work 35 years ago with C, and for the entirety of those 35 years, everybody I know has switched off lint.

    Why? Because (and you may correct me with some whizzy new implementation) lint was yer basic hacky *nix tool with very little in the way of an AST or semantic checks (compare and contrast to Roslyn, or whatever the equivalent is on the JVM). You want 25+% false negatives? Sure. Be my guest. Trawl through those 10,000 warnings and try not to die of despair.

  • Kythyria (unregistered) in reply to Sole Purpose Of Visit

    So basically lint was more of a wtf than anything it detected? Sounds... fun (and fanboys being what they are, there's probably still someone swearing by rather than at it).

    Lint being terrible in a "what's an AST" sort of way is a great example of why "text is a universal format" is wrong. It's universal in that one-off hacks can use string processing but if you need something that actually understands the data, text vs binary is the least of your worries.

    And the best way to do that in this context is to reuse the compiler itself! Why it took so long for compiler-as-library to catch on I don't know.

  • Duke of New York (unregistered)

    Writing code either to succeed against the odds or fail catastrophically and restart is the PHP way

  • dereferenced null pointer (unregistered)

    Or it was a debugging catch to have a breakpoint for a debugger in the catch block?

  • progo (unregistered)

    Lazy fix: can't you just catch(ZendException) {}? I'm pretty sure I've done that, in PHP. Don't hate me.

Leave a comment on “An Exceptional Warning”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article