• bvs23bkv33 (unregistered)

    ((price*)null)->getDellDiscount();

  • me (unregistered)

    UFO is a German union. That's just their name. Although the pun mught be intentional.

  • Oh well (unregistered)

    UFO (Unabhängige Flugbegleiter Organisation) is the name of Lufthansa's flight attendants' union. The statement still sounds funny, almost like an intended pun.

  • NULLPTR (unregistered) in reply to bvs23bkv33

    Access violation: Dereferenced Null-Pointer

  • negative infinity (unregistered)

    discountProviderFactoryRepo.getProvider().factoryForProducts([](x) -> x != (product*)(86 - 86)).setOnSale();

  • predecssor (unregistered)

    Nothing to do with French, somewhere deep in the archives I have a screenshot from a popup in Windows 98 (either OS or maybe a zip util) saying, "Error: The operation was a success."

  • my name is missing (unregistered)

    I never trust the French with my exceptions either.

  • Chronomium (unregistered)

    This is part of the plan for getting back at Quebec for being a jerk to English people.

  • (nodebb)
    "Hmmmm...Do I really trust Google Play Music to manage my Google Play Music library?" Ryan S. writes.

    I definitely wouldn't. Google Play Music can usually handle playing music files, but it sucks at managing pretty much anything, like playlists.

  • NULLPTR (unregistered) in reply to negative infinity

    Does not compile. C++ Lambdas require {} pairs around the function itself and java or C# don't use Pointers

  • Pierre Lebeaupin (unregistered)

    Rendez-vous. Toute résistance est inutile. Préparez-vous à être assimilés.

  • Scott (unregistered)

    I happened to get caught up in a Lufthansa Warnstreik a few years back. I hope Pedro was able to make alternate arrangments.

  • Google Play music (unregistered)

    If you look at the capitalization, it makes sense. Google Play Music wants access to Google Play music library, not to Google Play Music library

  • (nodebb)

    The operation succeeded.... but the patient died.

  • Kashim (unregistered) in reply to NULLPTR

    To be clear, C# does use pointers. It uses them a lot. It just forces the person writing the program not to use them, unless they are willing to mark their code "unsafe", in which case they can do whatever they want.

  • sizer99 (google)

    "Adrien wrote, "The exception L'opération a réussi (Operation succeeded) being thrown leads me to believe there is nothing wrong here and this application is simply intolerant of the French language"

    Nah, Microsoft stuff does this all the time even with English. The classic 'Operation Failed: Success' error dialog is older than the WTF blog is.

    This happens whenever something sets the error flag but doesn't set the error code. When displaying the message, you call the method that turns the error code into the error string, and since it's 0 you get 'Success' in English or 'réussi' in French.

  • Simon Clarkstone (unregistered) in reply to sizer99

    I thought a common way that could happen is:

    1. An I/O operation encounters an error, so it sets a global variable ("errno") indicating the specific error condition and returns a flag saying there was an error.

    2. The returned flag being set causes the mechanism for showing the error message to start running.

    3. Another I/O operation sneaks in (perhaps as part of step 2 or perhaps in another thread of execution) and succeeds, which sets the global error code back to "no error"

    4. The mechanism for showing the error reads global error code and displays the contents (Operation succeeded).

  • Neveralull (unregistered) in reply to sizer99

    Having “success” for a default error code is a very bad idea. Even “unspecified” would be better, if an error occurs but the programmer forgot to set an error code.

  • (nodebb) in reply to Neveralull

    So that developers would have to explicitly set an error code of "Success" when their code completes without an error.

  • (nodebb) in reply to Watson

    So that developers would have to explicitly set an error code of "Success" when their code completes without an error.

    That's a good idea anyway. That said, some functions will deliberately and usefully set a non-success last-error state even when they succeed.

    The example that springs to my mind is the Win32 CreateMutex call for a named mutex. If a mutex by that name already exists, CreateMutex will return a handle to it, but also set the Windows equivalent of errno to ERROR_ALREADY_EXISTS. The docs don't say what value is used if CreateMutex had to create the mutex, but I'd put money on it being ERROR_SUCCESS, to protect against the case where the "last error" was already ERROR_ALREADY_EXISTS.

  • jgh (unregistered)

    This is why it's a better idea not to return an error flag and an error number, but just solely an error number, and the error number being zero is itself an indicator of 'no error'. Otherwise you get exactly this problem of a caller checking the error flag, seeing it set, and then attempting to report errormessage[0] as an error.

    if(result=do_thing()) report_error(result); sorta thing

  • NULLPTR (unregistered) in reply to Kashim

    C# has a different lambda operator so it isn't C#. C# uses => instead of ->

  • (nodebb)

    Good catch that UFO is a union. I can also sympathize with the admin Dan article… I figure something like this may have happened:

    1. A long, long time ago, while the application was in its infancy, a DBA named Dan decided that he needed a fake article so he could properly test the application. It initially had some nonsensical but easily memorized name for the DBA. devs etc. convenience. Most likely, a database column was also added ad hoc, or had already been there for future-proofness: a boolean named "display". Non-displayable items were ignored unless a special debugging flag was set in the application. Everything went nicely and the fake item did not show up on the customer's side.
    2. Other DBAs kept deleting the fake article thinking that it had been created erroneously or as a prank. Due to team growth or just turnover, direct communication became tedious. Eventually, Dan decided to clue in other DBAs by naming the restored fake item as seen here. That "worked" in the sense that the article now persisted.
    3. Years or possibly eons later, while Dan and the original crew had already left for greener pastures (or were complimented out, who knows), someone discovered the "display" flag, decided that it was redundant, and removed the check from the application. Since it can be useful to exclude articles from a search, I reckon that they switched to a more general approach, e.g. comparing the customer's country code to a set of predefined lists or whatever other plausible check for an online store you can think of. During this process, it was not discovered that the "Admin-DAN DO NOT DELETE THIS PRODUCT" item changed from hidden to visible.

    Just an hypothesis, of course, and still a WTF on multiple levels (for one, application of the "protoduction" process anti-pattern), but at least there is a possibility that whatever happened is half-way understandable to someone knowing the details.

  • sizer99 (google) in reply to Neveralull

    Oh, this is all a bad idea, especially the bit about having a global variable for the error code. Besides people not setting it properly, as Simon Clarkstone pointed out this means something on another thread/task can blithely overwrite your real error. But that's how they did things back in 1990.

  • Ulysses (unregistered)

    Geeze Louise. Cue the Braniff plane! I can't believe some of these comments. errno has been thread-local—not even a plain variable—for ages now on real OSes, long before C++11 mandated its safety. And $err (VS debugger pseudovariable notation) has always been, of course.

    Whenever I saw 'Whoa, error! The operation completed successfully.' back in the day, I always imagined some reusable error handler had indirectly SetLastError() before the query.

Leave a comment on “Watch the Skies!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article