Random Thread

[zyxw59]

I love the smell of coffee, find the taste alright, but my stomach disagrees with the caffeine content (or maybe something else; decaf still makes me feel sick, but to a lesser extent than regular) Fortunately, black tea is sufficiently caffeinated to give me a productivity boost without making me feel sick, and it also satisfies the part of me that enjoys sipping a hot drink.

[zompist]

I quite like coffee with a lot of milk and sugar.

Good! Some people, like my parents, would try to make you feel bad for not drinking it black. But plenty of cultures around the world, including some with centuries-long coffee traditions, take their coffee with sugar and plenty of it.

(I don't use milk except if I want cold coffee.)

[Raphael]

Another thing that's weird about me is that I like both tea and coffee, as long as the coffee has enough milk in it. A couple of times, when I was at home, I couldn't decide whether I wanted tea or coffee, and ended up making a mug of each.

[Richard W]

I love errors that just say that something failed, without stating what or how or giving any meaning which might help resolve them.

I can remember a requirement that all error messages be documented. My immediate reaction was that the easiest way to meet that requirement was to simply output 'Something went wrong' in every case, as that seems much easier to document.

[foxcatdog]

I hear that there are people who exist who don't enjoy both tea and coffee but instead are on "teams" for one or the other.

[alynnidalar]

I'm sure my input is fascinating to you all, so I will add that I am firmly in the "love the smell of coffee, can't abide the taste" camp. Also can't do black tea. "Lighter" teas like green tea are completely fine, but unless it's very watered down, I just can't abide standard black tea.

I've heard that the reason some people don't like tea/coffee is because they're particularly sensitive to tannins. I've wondered if this is why I dislike coffee and black tea so strongly, but on the other hand, I don't mind dark chocolate, which also has lots of tannins.

[Travis B.]

I love errors that just say that something failed, without stating what or how or giving any meaning which might help resolve them.

I can remember a requirement that all error messages be documented. My immediate reaction was that the easiest way to meet that requirement was to simply output 'Something went wrong' in every case, as that seems much easier to document.

Even a simple exception trace that the user can copy and paste into an email would be more helpful (to the developer) than nothing, since oftentimes at my work an exception trace is far more helpful for fixing the issue than just saying that something broke.

[mèþru]

I like coffee chocolates and coffee ice cream but not actual coffee. The smell is nice though.
I also like yerba mate, but ever since I've started taking medication for my ADHD I've been advised not to drink it because we have no idea how it'd interact.

[chris_notts]

Even a simple exception trace that the user can copy and paste into an email would be more helpful (to the developer) than nothing, since oftentimes at my work an exception trace is far more helpful for fixing the issue than just saying that something broke.

I disagree strongly with this as the only strategy. I've had colleagues accept crashing and printing a traceback as an "acceptable" behaviour for any abnormal conditions, and in my experience non-technical users hate it. The text is frustrating because it's meaningless to them, all they know is that their application incomprehensibly crashes. I always think that:

1. Easily fixable errors should be recovered from
2. If something's going to fail, it should fail fast. Never suppress an error without fixing it if it might pop up again in 5 or 10 minutes, when the user's more committed to the process.
2. If something goes wrong, the application should say in plain English approximately what went wrong. E.g. was it a network error, a file access error, ....
3. Tracebacks should be logged, but they're for the developer, not the user. I normally either save them to a log file the user can email to me, or have a button that gathers together all the information (including inputs and logging) needed for a bug report.

[Travis B.]

Even a simple exception trace that the user can copy and paste into an email would be more helpful (to the developer) than nothing, since oftentimes at my work an exception trace is far more helpful for fixing the issue than just saying that something broke.

I disagree strongly with this as the only strategy. I've had colleagues accept crashing and printing a traceback as an "acceptable" behaviour for any abnormal conditions, and in my experience non-technical users hate it. The text is frustrating because it's meaningless to them, all they know is that their application incomprehensibly crashes. I always think that:

1. Easily fixable errors should be recovered from
2. If something's going to fail, it should fail fast. Never suppress an error without fixing it if it might pop up again in 5 or 10 minutes, when the user's more committed to the process.
2. If something goes wrong, the application should say in plain English approximately what went wrong. E.g. was it a network error, a file access error, ....
3. Tracebacks should be logged, but they're for the developer, not the user. I normally either save them to a log file the user can email to me, or have a button that gathers together all the information (including inputs and logging) needed for a bug report.

Oh I agree with all of this completely.

[Curlyjimsam]

I like coffee chocolates and coffee ice cream but not actual coffee. The smell is nice though.
I also like yerba mate, but ever since I've started taking medication for my ADHD I've been advised not to drink it because we have no idea how it'd interact.

Coffee flavoured things are worse than coffee itself, for me.

[Richard W]

2. If something goes wrong, the application should say in plain English approximately what went wrong. E.g. was it a network error, a file access error, ....

And cut out the features that make the application much more useful so as to output the plain English? Budgets are limited. Additionally, tracking down the error in the program tends to be non-portable, and is vulnerable to changes to the operating system.

Or should I interpret this as being in the specification register, in which 'should' is an auxiliary that cancels a sentence containing it in the principal clause?

[chris_notts]

2. If something goes wrong, the application should say in plain English approximately what went wrong. E.g. was it a network error, a file access error, ....

And cut out the features that make the application much more useful so as to output the plain English? Budgets are limited. Additionally, tracking down the error in the program tends to be non-portable, and is vulnerable to changes to the operating system.

Or should I interpret this as being in the specification register, in which 'should' is an auxiliary that cancels a sentence containing it in the principal clause?

Of course there's a limit to how much effort should go into this. But whatever language you're using, you must know approximately what you were doing when the error occurred? I mean, if you have a calculation that involves reading some data, doing some calculations and then saving the result, you'll know at the very least which of those three phases encountered the error. And if you're using a modern high level languages with catchable exceptions instead of error codes, you'll get an indication almost for free from the exact type of the exception. I don't see what's expensive about converting where and what into a simple English sentence.

[Richard W]

Of course there's a limit to how much effort should go into this. But whatever language you're using, you must know approximately what you were doing when the error occurred? I mean, if you have a calculation that involves reading some data, doing some calculations and then saving the result, you'll know at the very least which of those three phases encountered the error. And if you're using a modern high level languages with catchable exceptions instead of error codes, you'll get an indication almost for free from the exact type of the exception. I don't see what's expensive about converting where and what into a simple English sentence.

You surprise me about the catchable exceptions. Back when I was working with Ada on VAX/VMS, the only way to make most exceptions intelligible was to look at the error chaining in the traceback to find, for example, what sort of error was being raised as a CONSTRAINT_ERROR. And where do you put the error for calculating the area of a triangle with sides of 3, 4 and 8? If the input checker doesn't catch it - and input checking significantly slows down coding, so you have to expect errors to do it - do you call it a calculation error? And what do you do about negative square roots? (We've known a firmware upgrade produce negative square roots for some valid input bit patterns.)

I hope I'm missing something, but another problem with catching exceptions with handlers is that one tends to lose information on where the problem occurred. I've found that for development, it's far better if I can get a core dump or, even better, be thrown into the debugger.

[chris_notts]

There's an 80/20 thing here. You can give the user a rough idea what went wrong 80% of the time with 20% of the effort. Once it gets hard, there's a question about whether it's worth the effort and code complexity to get more specific. But what users I talk to generally don't like is:

AN ERROR OCCURRED:
100 lines of traceback

As the only thing they see whenever something goes wrong. Especially when the program can easily tell them how to fix it, e.g. "error: intra-array cable voltage must be positive". I think there's a compromise here.

[alynnidalar]

Users do not read error messages. 90% of the time you can't even get them to read normal text, let alone errors, and the percentage only goes up as the messages become longer and more complex. If you want any hope of the average user reading an error message--and especially if you want them to do something based on it--then your error message must be short and extremely non-technical.

If you need stack traces, then rather than show them to the users up front, you should log them quietly. This could be to a text file, a database, or simply emailing the programmer, but expecting the average user to a) understand that this incomprehensible message that popped up is meaningful, b) save it in a useful fashion, and c) send it to you simply will not happen the majority of the time. At best you're going to get someone going, "I got an error message!" "Okay, what was the error message?" "Uhhhh I don't know, I already closed the window." If you didn't log the stack trace somewhere yourself, displaying it to the user won't do you any good.

(if you're dealing with other techy people, then the odds of them reading error messages improves slightly; perhaps you have a 20% chance they'll read the brilliant, carefully-crafted error messages that you slaved over, and you may consider offering more details)

Finally I would be remiss if I didn't mention the other main reason you shouldn't show end users stack traces, especially for web applications/things with databases: it's just asking for someone to discover and exploit vulnerabilities in the system. If you're doing open source or we're talking a small offline application, then okay, but otherwise, it's a big security risk!

[alice]

Users do not read error messages. 90% of the time you can't even get them to read normal text, let alone errors, and the percentage only goes up as the messages become longer and more complex.

Indeed. You may generate something which says:

"Error: value given for parameter foo is too large (should be less than 42)"

and the typical user's reaction will be "I don't care what went wrong; I want to know how to fix it".

[chris_notts]

I have to admit that the users of my code are maybe atypical: they're not programmers but they are technical users in other fields such as engineers, quants etc. However, I've found that helpful error messages easily reduce the flow of support queries by 50%+. Which is a good thing, since first-line support are mostly not domain experts, so otherwise I'd end up spending my entire working life doing support for past work.

[Richard W]

There's an 80/20 thing here. You can give the user a rough idea what went wrong 80% of the time with 20% of the effort. Once it gets hard, there's a question about whether it's worth the effort and code complexity to get more specific.

That is indeed the problem with trying to provide helpful error messages. One partial solution is to force the programmer to use the program.

But what users I talk to generally don't like is:

AN ERROR OCCURRED:
100 lines of traceback

As the only thing they see whenever something goes wrong. Especially when the program can easily tell them how to fix it, e.g. "error: intra-array cable voltage must be positive". I think there's a compromise here.

Would said users have access to the source code? Even this level of error messaging gets painfully tedious compared to being able to look at the traceback and then at the line where the error was detected. It's even worse when there are multiple intra-array cable voltages. (We're also assuming that the problem isn't a misregistration between inputs provided and inputs required.) Unfortunately, traceback to the relevant line isn't always available, especially in portable code. There's one thing with this example that I don't like about a requirement to document all error messages. This is an example of a self-documenting error message, which probably wouldn't be counted as documentation.

There are also the error messages which indicate a problem with the logic of the program. Generally, the author must sit down and think about how to fix the problem.

[Linguoboy]

Someone tried to tell me today that polenta is "properly" translated as "grits". As. If.