Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've just come across (for the 47 millionth time) some code that looks like this:

except IOError, e:
  print "Problems reading file: %s." % filename
  sys.exit( 1 )

My first reaction is very visceral: the person who coded this is a complete idiot. How hard is it to print error messages to stderr and to include the system error message in the string? It certainly used to be the case that, for simple programs (command line filters), best practice was to print error messages to stderr and (when appropriate) to include the system error in the message. A very large percentage of developers no longer follow those rules. Many questions of the form "what is best practice for error messages" include answers about massive logging frameworks and exception handling mechanisms that do not apply to the simple filter. Has best practice changed? or is failure to include system error messages and printing error messages to the wrong stream the mark of a novice?

share|improve this question
3  
They may not be a complete novice, only a Python novice. Maybe they carried over an error-handling practice that they picked up somewhere else, and it worked for them, so they kept it. Maybe this system was originally a demo, never intended to live longer than a single presentation but somehow it did and the crappy code survived with it. Maybe it was copy-paste coding that printed a message, and at that time, it was good enough. –  FrustratedWithFormsDesigner Jun 29 '11 at 15:41
3  
Your question reads very much like a rant. Is there a problem to be solved here? "X sucks, am I right?" questions are off-topic. –  Anna Lear Jun 29 '11 at 16:12
    
@Anna I do not understand why what I consider to be basic things are ignored. I suppose there is a bit of 'am I right?' here, in that I fundamentally believe that error messages should go to stderr and include a reason, and it seems that a large majority of the programming community either disagrees or just doesn't think it is important. –  William Pursell Jun 29 '11 at 16:16
2  
@William Right, but questions here are intended to be about practical, solvable problems. Your question doesn't seem to fit that. Is it important for you to judge if someone is a novice based on their exception handling? Are you looking for suggestions on ways to correct that developer's behaviour or do you just want the community to say "yes, you're right"? –  Anna Lear Jun 29 '11 at 16:57
2  
This could have been asked as a decent, constructive question, but as of right now it's little more than a rant. Note where it says in the FAQ about questions you shouldn't ask: ...there is no actual problem to be solved: “I’m curious if other people feel like I do.” –  Aaronaught Jun 29 '11 at 17:05
show 1 more comment

5 Answers

I think you're being too rude here. Especially since your suggestion (including system error message) can be criticized. I don't know how does it happen in Python, but in .NET Framework, exception messages are not expected to be displayed to the end user. They are written for developers, and only for them. There are at least three reasons for that:

  • The language of .NET Framework may be different from the UI language (including when the UI language is configurable by the user).
  • The exception messages are sometimes scary or not helpful for an end user (Would you like to show to your user something like: "Object reference not set to an instance of an object"?).
  • Giving an exact exception message is not very secure.

In his answer, Thorbjørn Ravn Andersen points the two most important problems with the code: no logging and abrupt exit. But what about the error message itself?

I would say it's not so bad compared to others. I see a lot of strange, wrong, unhelpful messages even in commercial popular products. Examples:

  • When dealing with the names of files which exceed 259 characters, Microsoft Word tells us a very helpful story that our floppy drive is too small (on a machine where there is no floppy drive at all) and suggests, guess what?... that we update our antivirus.

  • When something wrong happens in Visual Studio, sometimes it tells that, well, something wrong happened, but it doesn't bother to tell us what, and doesn't even want to tell where log files are (are those errors logged, by the way?).

  • On my old phone, when trying to send mails, it tells me something like "Operation failed". Oh, thanks for such details, now I know precisely what was wrong!

  • etc.

DailyWTF has also lots of examples of such error messages. Including pessimistic messages like "Error: success".

In many cases, you can see something like:

try
{
    // Thousands of lines here (hopefully not in the same method).
}
catch (Exception) // After all, who cares about *what* is exactly the exception?
{
    MessageBox.Show(@"Something went wrong. Please restart your application.
If you see this message again, contact your administrator.");

    // And yes, we don't want to be polite, don't want to tell what's wrong,
    // but want to suck administrators by telling them that they must contact
    // themselves.
}

If you put a error message, if it's not correctly written (because you don't have time, or whatsoever), at least:

  • Don't put stupid suggestions, like "contact your administrator",
  • Make the error searchable on internet (including some error number can help), or at least make sure that there is only one error in a specific context.
  • Ensure that the user can report you the error. Can you solve quickly the bug report if it says:

Bug 1024: I think I've found a bug. When working with your great and user friendly application, sometimes, it randomly displays "The application encountered a fatal error." message. Can you solve it, please?

share|improve this answer
    
Perhaps I was a bit rude, and I apologize for that. I blame frustration. Your answer (and others) point out an interesting cultural divide: the simple command line utility that "does one thing" can live within a framework that provides error logging, etc, but the program itself is perfectly free to abort early and does not worry about such details. In that programming paradigm, the only way a framework can be built around it is if certain rules are obeyed: writing errors to stderr is an important rule. –  William Pursell Jun 29 '11 at 16:44
    
"Contact your administrator" isn't always a stupid suggestion - for example, if a privilege check fails, that may be exactly what the user needs to do. –  Aaronaught Jun 29 '11 at 17:22
    
@Aaronaught: agree, it's not always the case. But in many cases, it's the administrators who see those suggestions, or the home users who don't have any administrator and don't have any clue about what to do next and who must be contacted. –  MainMa Jun 29 '11 at 19:20
add comment

I think my number is around the same (47 million, give or take) of running into somewhat equivalent C# code:

try
{
    // Tricksy code be here.
    return true;
}
catch (Exception ex)
{
    Logger.Error("This error occurred: " + ex.Message);
    return false;
}

So, in our log, we wind up with a number of oh-so-useful "Object reference not set to an instance of an object" just sitting there with no other context. How hard is it to actually type LESS and have it be:

    Logger.Error("This error occurred: " + ex);

Much more useful information for the developers.

Now as to your second question: is the developer a novice? Maybe, maybe not. But certainly the developer didn't think ahead to what might be needed to do forensic reconstruction of an error.

share|improve this answer
2  
I'm sorry to hear you're experiencing the same problems as the OP, but I feel that your post just repeats the problem stated in the question doesn't answer it at all. –  Anna Lear Jun 29 '11 at 16:11
    
Such can be said for every answer on this question - most address good practices, but do not answer the OP's two direct questions. –  Jesse C. Slicer Jun 29 '11 at 16:38
    
Re: good practices, perhaps my questions really do boil down to the tired question: what is best practice for error messages? Everytime I see that question I end up disagreeing violently with 80% of the answers. There are settings in which "logging" errors is necessary, and setting in which printing a string to stderr is sufficient. There are settings in which throwing an exception is the right thing to do, and settings in which calling exit() is just fine. Perhaps my visceral reaction is just a culture clash. –  William Pursell Jun 29 '11 at 16:57
    
@William: This is one area I wholeheartedly agree with Joel Spolsky in his book of essays on software development (now looking for a link... ah! found it!) regarding error reporting here: fogcreek.com/fogbugz/docs/30/UsingFogBUGZtoGetCrashRep.html . This is what I would consider a good start. There's obviously more you can do for your users in telling them a good plain English explanation of what happened and what can be done from there. –  Jesse C. Slicer Jun 29 '11 at 17:14
add comment

One potential healthy reaction after you get through the disgust (and its normal to feel disgust):

Could it have been that the programmer who did that was under such a severe time crunch that he/she was grateful just to have the time to be able to report any error string at all? The programmer him or herself may wish they had the time do polish everything, but did the best they could under very difficult circumstances.

I've seen a lot of code where I work that's terrible and ugly but was written by very smart people trying to get the company through the next pay cycle. I'm just grateful it was written because them getting that project done has enabled me to have a job where I can complain about how bad the original code is :)

share|improve this answer
1  
Heh. When I started working where I am now, I was amazed that the code was so bad. Now I'm amazed that it is as good as it was. If you have to go from the recognized need for an application to production in a week or less, clean and pretty isn't as important as functional. –  Satanicpuppy Jun 29 '11 at 16:17
add comment

While it's hard to excuse error handling with this little information in, the reality is that scoping error handling is actually pretty tricky.

Too little and you end up unable to troubleshoot even the most straight forward of problems, too much and you end up with logs that cycle before you can get to them, fill servers and where writing the error handling takes as long as writing the code without having any idea whether it's even going to be problematic (seriously, I've seen code which dumps every variable out on every function call but which has never gone majorly wrong).

In this example it might be worth asking how long has this code been around and what does it do. If it's been around for 10 years and it's still doing this it's probably a sign that the code is actually trouble free and that any error handling is unnecessary.

And depending on what it's doing it may be that either you don't need to know about the nature of the error (because all you care about is that it failed and it's irrelevant why) or that the code does such as specific thing that anyone who understands it will be able to guess what's happened 99% of the time with no additional information.

Ultimately you're right, it's basically no more work to put in the extra information and it should happen but you're harsh saying you have no respect for them.

It's probably a case of inexperience or time pressure, or writing something quick and dirty which they thought would run once and somehow ended up in still production a decade later. Those are all a bit rubbish but we've all been there and let the programmer who has never turned out less than perfect code cast the first stone.

In terms of specifics I'd fix it and maybe politely mail the team saying that you've noticed this and wouldn't it be better and no more work to include the standard message (including a nice code sample so they don't even need to look it up).

But on a wider note getting error handling right is harder than it seems.

share|improve this answer
add comment

Either fix it yourself or report a bug to the programmer responsible for this to fix it.

Additionally there are two code smells in this:

  • No logging framework.
  • Code should not just abruptly exit.

It is important to have the exception bubble to the main method, have it logged properly and THEN exit. This allows upstream code to properly wrap things up - close files, empty buffers, release system resources, etc.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.