• (nodebb)

    return bOK ? true : Frist(false);

  • Mischa (unregistered)

    At least it allows debugging for specific failures.

  • (nodebb)

    Another overload, string Failed(string value) { return value; } Then call it like this: return Failed("I suck at coding");

  • Skunk (unregistered)

    This might not be as useless as it looks. The Failed function is a fine place to set a breakpoint in a debugger to capture multiple failures. The stack trace then tells you where the failure occurred.

  • RC (unregistered)

    How about a place to put a debugger stop point? When something failed, it would trigger the debugger to stop.

  • anonymous (unregistered)

    I thought it was going to be if (Failed(FunctionThatReturnsTrueOnFailure()) as a way to make the code read nicer. Although in that case, inverting the value inside the Failed function would make more sense as usually true means "success" when used as a return value in this kind of situation.

  • anonymous (unregistered)

    To everyone talking about debuggers: Exceptions can already do this. I might be wrong but I'm pretty sure any good debugger should be able to break when an exception is thrown (even if it's caught), and filler by type of exception. You'll get a stack trace and the ability to see where the error is being handled (if applicable).

  • Bruce (unregistered) in reply to anonymous

    You would think a debugger could do this - but some of Microsoft's libraries (most notably the Xml and Json ones) throw exceptions as part of their "normal" operation. So if you enable the setting to break on exception you end up in Microsoft's libraries most of the time. The newer versions of Visual Studio will stop and on those exceptions and present a check box to allow you to skip the exception in whatever library you are in - so at least you only suffer once.

  • (nodebb)

    Here's how you make the "debugger break point" solution not be a WTF

    // No-Op Function to serve as a convenient break point for debugging static bool Failed(bool value) { return value; }

    Addendum 2019-05-06 09:56:

    Edit: Apparently line breaks were stripped. Hopefully it's short enough to understand regardless

  • (nodebb)

    I'm with the people who say this is a reasonable place for a breakpoint.

    Notice that it takes a parameter, you can do things like:

    error_code = Failed(ERR_FILE_NOT_FOUND);

  • grasshoppa (unregistered)

    Sadly, ENUMs would be an improvement over this.

  • Anon (unregistered)

    First of all, breakpoints and debugging make this a reasonable approach. In the release executable, the function call would vanish and it'd just put the value in place. It still seems dubious, but it is nowhere near the wtf levels you are claiming it to be.

    The real wtf is the author of this article suggesting exceptions. I mean, they're great if you want to restrict your target platforms, add bloat in the resulting binary, remove a bunch of useful optimisations, and keep what's essentially debug code in your release build. Exceptions have their place in a few circumstances, but this is definitely not one of them.

  • (nodebb)

    Either there used to be logging in there or it's a debugging assist since for some reason they aren't using exceptions. I don't think it's a WTF.

  • Ulli (unregistered)

    @Double Negation: Shall I call Failed(true) if someting truely really seriously failed and Failed(false) if everything went right and nothing failed?

  • DrPepper (unregistered)

    If you're running unit tests, you can spy on the Failed() method; then in your test you can assert that Failed was called (or not called); assert on the arguments to Failed, etc.

    Again, in a unit test, you can also override the return value of the Failed() call to force the code through a code path you could otherwise not reach.

    So from that perspective, it makes sense to me.

  • sizer99 (google) in reply to Loren Pechtel

    Even if you think avoiding exceptions is a good reason, the boolean being passed in is a complete WTF.

    Now you've got Failed(false) (which bizarrely means it did fail), Failed(true) (which means it failed but that's okay?) and Failed(FILE_NOT_FOUND) (okay, that one's obvious).

  • Jakub Narębski (unregistered)

    Also, if this was not C++ code but plain C code, then there are no exceptions ;-)

  • (nodebb) in reply to Anon

    the function call would vanish? ahahahaha

    No it wouldn't. It'd remain there getting called, whether or not you were doing a debug build.

    Exceptions are not expensive and display intent a lot more clearly. The real problem with them is getitng people to understand how to define exceptions so that you can do something useful when you catch them and aren't hammered by people adding new ones (or using runtime_error for everything)

  • Fernando Cacciola (unregistered)

    A really nice way to communicarte what failed without exceptions is to use the proposed std::expected utility class:

    https://www.youtube.com/watch?v=JfMBLx7qE0I

  • Stephan (unregistered) in reply to thosrtanner

    Any reasonably recent compiler toolchain would be able to auto-inline such function calls at link time. Even if it didn't, the call would still be an order of magnitude more efficient than throwing excptions and unwinding the stack.

    While I do agree that throwing exceptions is the best approach in general, you don't know enough of this particular project to make an appropriate judgement. Maybe the code must run on a reststicted environment such as a microcontroller.

  • markm (unregistered) in reply to sizer99

    I guess failed() takes an integer fail code parameter. If you don't have a fail code, you can use zero, but this coder disguised fail(0) as fail(false).

  • Richard Wells (unregistered)

    TOWTF is the declaration/assignment instead of declaration/initialization. Uninitialized variables bother me, even if for only 1 line of code.

  • Danya Generalov (github)

    Presently I'm afraid that it may be so that the function can be edited to always return true, this basically disabling all errors ever. It sounds too WTF to be true, but we've seen many times that nothing is too WTF...

Leave a comment on “If I Failed”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article