• FRiST (unregistered)

    How about you put an assert in the catch, so you can at least find errors in dev? </terrible idea>

  • TheCPUWizard (unregistered)

    "No errors, no matter what the cause, were ever to be allowed to be seen by the user."

    1. This approach is a major error
    2. I am a user of this site
    3. I have seen that error

    Endless loop - SELF-DESTRUCT.

  • Ann Onymous (unregistered)

    I used to program like that before I started my first professional job... I don't any more :P

  • Some guy (unregistered)

    What about bothering the developers? Maybe by logging or emailing the failure?

  • There, fixed it (unregistered) 
        try
    {
             SaveToBlobStorage();
    }
    catch (Exception ex)
    {
             _hiddenLog.Error(ex);
    }
  • Tom (unregistered)

    Reminds me of this:

    http://programmer.97things.oreilly.com/wiki/index.php/Don't_Nail_Your_Program_into_the_Upright_Position

  • WonkoTheSane (unregistered) in reply to Ann Onymous

    Yeah... Much easier to just define ONE global error handler to swallow them ALL!!!!

    MWAAHAHAHAHAHAHAHA

  • WonkoTheSane (unregistered) in reply to There, fixed it

    try { SaveToBlobStorage(); } catch (Exception ex) { //TODO : Dont forget to log this }

    FTFY :)

  • Ørjan Langbakk (github)

    So... When this fails, as it will do, and the customer want to retrieve the data stored, and it's not there... That's when the customer bothers the devs, correct?

  • (nodebb) in reply to Ørjan Langbakk

    No, that's when the boss reams the developers for having done something that bothered the customer.

    If the developers are smart, they'll ignore the stupid boss and put in code to do something graceful rather than just dumping 40-deep Java stack traces into the HTML stream. If the data-retrieval fails, the result is going to bother the customer, no matter what it is, so make it something that explains to the customer that there is a problem, and log the details so that the poor sods who have to diagnose it can do so.

    Striking a balance between "An error has been to your computer" at one extreme and that stack trace on the other is hard, and depends on the sort of users you expect to see it, but strike it you must.

  • Oliver Jones (google)

    Yes, this.

    Then there's "Never. Train. The. User." This is a big problem when providing health care IT services to for-profit hospitals and chains.

  • MiserableOldGit (unregistered) in reply to Tom

    Or better still http://www.drdobbs.com/cpp/double-plus-good/184404838

  • Tree (unregistered)

    The variant of this that I teach people is No One Wants to Talk to the Client.

    It serves the dual purpose of mitigating the fear in my people and also explains many bad behaviors observed in coworkers and clients.

  • VB6 (unregistered)

    On Error Resume Next

  • Eric Lizotte (google)

    Honestly.... What good is displaying an error a user won't understand to them? Logging to a remote source should get you every bit as far. Showing the user that an operation failed though is pretty necessary just for their knowledge's sake.

    I do wonder how (if?) they did any UI validation

  • Nathan (unregistered) in reply to Eric Lizotte

    If we stop displaying errors a user won't understand, then we'll significantly reduce the content of the articles TDWTF puts out on Fridays....

  • MiserableOldGit (unregistered) in reply to Eric Lizotte

    Well it depends what happened, if the data they just typed in didn't actually end up in the database when they pressed save they probably ought to be warned, no?

    I do agree most error messages are unintelligible drivel, though, even to the people guilty of raising them.

  • Rob greene (google)

    As a user of software, when something does not do what I want it to do, I want to know how to get it fixed. It is doubtful that a stack trace would help but here are some examples where better messages to the user would help.

    • From Plex when I wanted to view a stored video: "Sorry, unable to show that video" At this point I want to see my video and Plex is not showing it to me, nor telling me what I can do to see my video.

    • From Windows when I want to delete a file: "File in use" So, who is using that file? I want it deleted and something is using it. Why don't they tell me who is use the file I want deleted? I need to delete that file. Why don't you delete it anyway?

    User information needs to be more than "Sorry" or pretending that it worked, the user needs to know what actions need to happen in order to make things do what they want it to do.

  • Nobody Important (unregistered)

    How about:

    protected void SaveToBlobStorage_OrNot_TheresReallyNoWayToTell_ButTheCustomerProbablyWontMindIfItFailsSilently_AtLeastWeDidn'tBotherHim() { try { SaveToBlobStorage(); } catch (Exception ex) { } }

  • Quirkafleeg (unregistered)

    The real solution to all this is for the entire team to increasingly annoy the boss by playing the game "Always. Bother. The. Boss"... The rules are simple:

    1. Try and ask the boss the most stupid question that earns the response "Never. Bother. The. Customer."
    2. Bonus points are awarded for crow-barring in silly words (like 'blancmange', 'gusset' or 'carbuncle')
    3. Start taking bets as to when the boss realises what is happening
    4. The loser is the one who gets fired!
  • Uhm... (unregistered)

    Windows is the "best" example of "never tell the customer what's actually going on".

    like, recently i tried to install win10 on my computer that runs linux (i know, big mistake).

    it installed fine, i had a bit of struggle with the bootloader, but once i managed to boot into windows, it took half an hour configuring things, and then tells me "windows can't be configured on this computer [Ok]" and rebooted.

    no way to find out what is actually blocking the installation process at this stage...

  • woiweoiueoi[u (unregistered) in reply to Uhm...

    I think you'll find Linux is the "best" example of "never tell the customer what's actually going on".

  • Zenith (unregistered) in reply to Uhm...

    Windows only really got like that in recent years through an aggressive strategy of importing H1Bs while trying to copy Google ("never ever finish or support anything") and Linux ("we're not lazy, we just expect our users to fix/fork our product for us").

    Seriously, though, the cognitive dissonance here is insane. People actually think if they don't provide a means to report bugs that it means there are no bugs. Sure is cheaper than hiring competent developers! Besides, we all know that no user has ever dropped a product/service that doesn't work, right?

  • scrutari (unregistered)

    ...catch (Throwable error) ...

  • Jeremy Hannon (google)

    I worked one place where the lead developer gave the opposite instructions. Never, ever, trap an error. That's right - even if you were to expect an error and have a way around it, you don't put error traps in because, whatever reason. All exceptions on the site are to roll to the global error handler and display an appropriate message for the user.

  • snoofle (unregistered)

    I once had to support a system that used other systems (not under our control) to perform various transactions. Invariably, the remote system being accessed would hang/error-and-not-return/etc and we'd get a support call: YOUR system is not responding. One day I'd had it and added a transaction-status screen. If your transaction timed out, it turned red. If you clicked on it, you got the specific remote system that wasn't responding, and the name, email and phone number of the remote team's support person and manager. It cut our support calls by 95%.

  • Kamil Czajko (google)

    Here I've fixed it for you, failing the first time was unlucky, what's the chances it it fail twice?

    protected void SaveToBlobStorageSafe() { bool success = false; while(!success) { try { SaveToBlobStorage(); success = ture; } catch (Exception ex) { success = FILENOTFOUND } } }

  • RLB (unregistered) in reply to Quirkafleeg

    More bonus points for combining this with the log approach: all exceptions are to send an e-mail, containing the full stack dump, to the manager.

  • Hrm... (unregistered) in reply to Nobody Important

    ...AtLeastWeDidn'tBotherHim

    What language are you using that allows for a ' in a method name and uses protected void?

    Oh, and how many syntax highlighters have failed on the ' so far?

  • Quite (unregistered)

    I discussed with a developer once the possibility of replacing error messages with pictures. Users never read error messages. But, when a user rings up and says: "I was doing my stuff, and all I got on my screen was a field of corn." Then the developer knows exactly what the problem is, because the picture with a field of corn on it appears only when, for example, there is a break in such-and-such a data connection.

    And so on.

    It won't solve all problems, but it will mean that the common problems that users suffer will be instantly diagnosable without the user saying "I dunno, it just vomited out a load of letters and numbers , and nobody got time for that ..."

    Never got round to implementing it, but it sure sounded like a cool idea.

  • dave (unregistered)

    I used to have to maintain legacy code originally written by a particular contractor whose trademark was empty catch blocks.

    Funnily enough some people prefer it - after i started outputting error messages for an internally-used site , there were comments that the code written by the contractor never went wrong whilst the new code was always giving errors. They refused to believe that the old code didn't actually work behind the scenes as surely if something had gone wrong it would have told them.

    TLDR; Sometimes people like to live in ignorant bliss

  • David Mårtensson (unregistered)

    Had a colleague that favoured the same approach. :(

    Have been fixing these for many years by at least adding reporting back to us so we can catch the problems and preferably give the customer some form of message.

  • V (unregistered)

    "No errors, no matter what the cause, were ever to be allowed to be seen by the user." This is actually a good policy for a lot of cases. It still does not stop you to log and/or send someone else details about the error. There's no WTF in the requirements here, just in the implementer/submitter.

  • Ulysses (unregistered) in reply to V

    http://i0.kym-cdn.com/photos/images/newsfeed/000/173/576/Wat8.jpg

    That's like the Emperor's New Clothes of software design.

  • RichP (unregistered)

    try { exit(); } catch { exit(); }

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to Quite

    A (still pre-release) game I play uses strange words for certain errors (mostly connection-related), like PELICAN and PEACHPIT and ALTAIR9000. The strangeness of the words makes them more memorable. (inb4 someone bragging that they figured it out, like they were some kind of super detective for using google)

  • nasch (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    Destiny uses animals for their errors - baboon, and so on.

  • MiserableOldGit (unregistered)

    I used to use a lot of profanity in my error messages.

    They were memorable, but not a good way.

    I got told to stop after a while.

  • My name (unregistered)

    Catching Exception is like the pull-out method, the problem has already occurred and all you win is the ability to forget about it until it bites you in the ass

  • Malky (unregistered) in reply to WonkoTheSane

    try { SaveToBlobStorage(); } catch (Exception ex) { //TODO : Dont forget to log this }

    FTFY... sorry that was triggering me a bit

  • sf. (unregistered)

    c'mon. My employer had a similar philosophy, and it worked.

    If 80% of the infrastructure crashes and burns, the remaining 20% should keep working as if nothing happened, and the rest should pretend it's working, or at worst trying to access some data.

    Of course there were all kinds of alarm bells that would go to the developers, to fix it ASAP. The services would try to make up valid-looking data or pull something obsolete from caches. The customer was never to see an error message.

Leave a comment on “Never Bother the Customer”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article