Don't Ignore that Error! - Revision history

Kevlin at 10:40, 10 July 2009

2009-07-10T10:40:14Z

Kevlin: Don't ignore that error! moved to Don't Ignore that Error!

2009-07-10T10:31:31Z

Don't ignore that error! moved to Don't Ignore that Error!

←Older revision

Revision as of 10:31, 10 July 2009

Petegoodliffe at 14:01, 6 March 2009

2009-03-06T14:01:27Z

←Older revision		Revision as of 14:01, 6 March 2009
Line 11:		Line 11:
	We report errors in our code in a number of ways, including:		We report errors in our code in a number of ways, including:
	* '''Return codes''' can be used as the resulting value of a function to mean "it didn't work". Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from <code>printf</code>?		* '''Return codes''' can be used as the resulting value of a function to mean "it didn't work". Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from <code>printf</code>?
-	* '''errno''' is a curious C aberration, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems — for example, what happens when you have multiple threads calling the same function?	+	* '''errno''' is a curious C aberration, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems — for example, what happens when you have multiple threads calling the same function? Some platforms insulate you from pain here; others do not.
	* '''Exceptions''' are a more structured language-supported way of signaling and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this:		* '''Exceptions''' are a more structured language-supported way of signaling and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this:

Kevlin at 14:19, 4 February 2009

2009-02-04T14:19:33Z

Petegoodliffe: I missed the extra tie-in to the opening story.

2008-12-04T15:27:37Z

I missed the extra tie-in to the opening story.

←Older revision		Revision as of 15:27, 4 December 2008
Line 15:		Line 15:

	try {		try {
-	/// ...do something...	+	// ...do something...
	}		}
	catch (...) {} // ignore errors		catch (...) {} // ignore errors

	The saving grace of this awful construct is that it highlights the fact you're doing something morally dubious.		The saving grace of this awful construct is that it highlights the fact you're doing something morally dubious.
		+
		+	If you ignore an error, turn a blind eye, and pretend that nothing has gone wrong, you run great risks. Just as my leg ended up in a worse state than if I'd stopped walking on it immediately, ploughing on regardless can lead to very complex failures. Deal with problems at the earliest opportunity. Keep a short account.

	Not handling errors leads to:		Not handling errors leads to:

Petegoodliffe: Spellings and minor edits.

2008-12-03T14:56:39Z

Spellings and minor edits.

←Older revision		Revision as of 14:56, 3 December 2008
Line 11:		Line 11:
	We report errors in our code in a number of ways, including:		We report errors in our code in a number of ways, including:
	* '''Return codes'''. A function returns a value. Some of which mean "it didn't work". Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from printf?		* '''Return codes'''. A function returns a value. Some of which mean "it didn't work". Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from printf?
-	* '''errno''' This is a curious C language ~~abberation~~, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems - for example, what happens when you have multiple threads calling the same function?	+	* '''errno''' This is a curious C language aberration, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems - for example, what happens when you have multiple threads calling the same function?
-	* '''Exceptions''' ~~Exceptions~~ are a more structured language-supported way of ~~signalling~~ and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this:	+	* '''Exceptions''' are a more structured language-supported way of signaling and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this:

	try {		try {

Petegoodliffe: New page: ''I was walking down the street one evening to meet some friends in a bar. We hadn't shared a beer in some time and I was looking forward to seeing them again. In my haste, I wasn't lookin...

2008-12-03T14:46:34Z

New page: ''I was walking down the street one evening to meet some friends in a bar. We hadn't shared a beer in some time and I was looking forward to seeing them again. In my haste, I wasn't lookin...

New page

''I was walking down the street one evening to meet some friends in a bar. We hadn't shared a beer in some time and I was looking forward to seeing them again. In my haste, I wasn't looking where I was going. I tripped over the edge of a curb and ended up flat on my face. Well, it serves me right for not paying attention, I guess.''

''It hurt my leg, but I was in a hurry to meet my friends. So I pulled myself up and carried on. As I walked further the pain was getting worse. Although I'd initially dismissed it as shock, I rapidly realised there was something wrong.''

''But, I hurried on to the bar regardless. I was in agony by the time I arrived. I didn't have a great night out, because I was terribly distracted. In the morning I went to the doctor and found out I'd fractured my shinbone. Had I stopped when I felt the pain, I'd've prevented a lot of extra damage that I caused by walking on it. Probably the worst morning after of my life.''

Too many programmers write code like my disastrous night out.

''Error, what error? It won't be serious. Honestly. I can ignore it.'' This is ''not'' a winning strategy for solid code. In fact, it's just plain laziness. (The bad sort.) No matter how unlikely you think an error is in your code, you should always check for it, and always handle it. Every time. If you don't, you're not saving time, you're storing up potential problems for the future.

We report errors in our code in a number of ways, including:
* '''Return codes'''. A function returns a value. Some of which mean "it didn't work". Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from printf?
* '''errno''' This is a curious C language abberation, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems - for example, what happens when you have multiple threads calling the same function?
* '''Exceptions''' Exceptions are a more structured language-supported way of signalling and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this:

try {
/// ...do something...
}
catch (...) {} // ignore errors

The saving grace of this awful construct is that it highlights the fact you're doing something morally dubious.

Not handling errors leads to:
* '''Brittle code''', full of hard-to-find crashes.
* '''Insecure code'''. Crackers often exploit poor error handling to break into software systems.
* '''Bad structure'''. If there are errors from your code that are tedious to deal with continually, you have probably have a bad interface. Express it better, so the errors are not so onerous.

Just as you should check all potential errors in your code, you must expose all potentially erroneous conditions in your interfaces. Do not hide them, and pretend that your services will always work.

Why don't we check for errors? There are a number of common excuses. Which of these do you agree with? How you would you counter each of them?
* Error handling clutters up the flow of the code, making harder to read, and harder to spot the "normal" flow of execution.
* It's extra work and I have a deadline looming.
* I know that this function call will '''never''' return an error (printf always works, malloc always returns new memory, and if it fails we have bigger problems...)
* It's only a toy program, and needn't be written to a production-worthy level.

←Older revision		Revision as of 10:40, 10 July 2009
Line 3:		Line 3:
	''It hurt my leg, but I was in a hurry to meet my friends. So I pulled myself up and carried on. As I walked further the pain was getting worse. Although I'd initially dismissed it as shock, I rapidly realised there was something wrong.''		''It hurt my leg, but I was in a hurry to meet my friends. So I pulled myself up and carried on. As I walked further the pain was getting worse. Although I'd initially dismissed it as shock, I rapidly realised there was something wrong.''

-	''But I hurried on to the bar regardless. I was in agony by the time I arrived. I didn't have a great night out, because I was terribly distracted. In the morning I went to the doctor and found out I'd fractured my ~~shinbone~~. Had I stopped when I felt the pain, I'd've prevented a lot of extra damage that I caused by walking on it. Probably the worst morning after of my life.''	+	''But I hurried on to the bar regardless. I was in agony by the time I arrived. I didn't have a great night out, because I was terribly distracted. In the morning I went to the doctor and found out I'd fractured my shin bone. Had I stopped when I felt the pain, I'd've prevented a lot of extra damage that I caused by walking on it. Probably the worst morning after of my life.''

	Too many programmers write code like my disastrous night out.		Too many programmers write code like my disastrous night out.

-	''Error, what error? It won't be serious. Honestly. I can ignore it.'' This is ''not'' a winning strategy for solid code. In fact, it's just plain laziness. (The wrong sort.) No matter how unlikely you think an error is in your code, you should always check for it, and always handle it. Every time. You're not saving time if you don't: ~~you~~'re storing up potential problems for the future.	+	''Error, what error? It won't be serious. Honestly. I can ignore it.'' This is ''not'' a winning strategy for solid code. In fact, it's just plain laziness. (The wrong sort.) No matter how unlikely you think an error is in your code, you should always check for it, and always handle it. Every time. You're not saving time if you don't: You're storing up potential problems for the future.

	We report errors in our code in a number of ways, including:		We report errors in our code in a number of ways, including:
-	* '''Return codes''' can be used as the resulting value of a function to mean "it didn't work". Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from <code>printf</code>?	+	* '''Return codes''' can be used as the resulting value of a function to mean "it didn't work." Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from <code>printf</code>?
	* '''errno''' is a curious C aberration, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems — for example, what happens when you have multiple threads calling the same function? Some platforms insulate you from pain here; others do not.		* '''errno''' is a curious C aberration, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems — for example, what happens when you have multiple threads calling the same function? Some platforms insulate you from pain here; others do not.
	* '''Exceptions''' are a more structured language-supported way of signaling and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this:		* '''Exceptions''' are a more structured language-supported way of signaling and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this:
Line 26:		Line 26:
	* '''Brittle code'''. Code that's filled with exciting, hard-to-find bugs.		* '''Brittle code'''. Code that's filled with exciting, hard-to-find bugs.
	* '''Insecure code'''. Crackers often exploit poor error handling to break into software systems.		* '''Insecure code'''. Crackers often exploit poor error handling to break into software systems.
-	* '''~~Bad~~ structure'''. If there are errors from your code that are tedious to deal with continually, you have probably have a poor interface. Express it so that the errors are less intrusive and the their handling is less onerous.	+	* '''Poor structure'''. If there are errors from your code that are tedious to deal with continually, you have probably have a poor interface. Express it so that the errors are less intrusive and the their handling is less onerous.

	Just as you should check all potential errors in your code, you need to expose all potentially erroneous conditions in your interfaces. Do not hide them, pretending that your services will always work.		Just as you should check all potential errors in your code, you need to expose all potentially erroneous conditions in your interfaces. Do not hide them, pretending that your services will always work.

←Older revision		Revision as of 14:19, 4 February 2009
Line 3:		Line 3:
	''It hurt my leg, but I was in a hurry to meet my friends. So I pulled myself up and carried on. As I walked further the pain was getting worse. Although I'd initially dismissed it as shock, I rapidly realised there was something wrong.''		''It hurt my leg, but I was in a hurry to meet my friends. So I pulled myself up and carried on. As I walked further the pain was getting worse. Although I'd initially dismissed it as shock, I rapidly realised there was something wrong.''

-	''But, I hurried on to the bar regardless. I was in agony by the time I arrived. I didn't have a great night out, because I was terribly distracted. In the morning I went to the doctor and found out I'd fractured my shinbone. Had I stopped when I felt the pain, I'd've prevented a lot of extra damage that I caused by walking on it. Probably the worst morning after of my life.''	+	''But I hurried on to the bar regardless. I was in agony by the time I arrived. I didn't have a great night out, because I was terribly distracted. In the morning I went to the doctor and found out I'd fractured my shinbone. Had I stopped when I felt the pain, I'd've prevented a lot of extra damage that I caused by walking on it. Probably the worst morning after of my life.''

	Too many programmers write code like my disastrous night out.		Too many programmers write code like my disastrous night out.

-	''Error, what error? It won't be serious. Honestly. I can ignore it.'' This is ''not'' a winning strategy for solid code. In fact, it's just plain laziness. (The ~~bad~~ sort.) No matter how unlikely you think an error is in your code, you should always check for it, and always handle it. Every time. ~~If you don't, you~~'re not saving time, you're storing up potential problems for the future.	+	''Error, what error? It won't be serious. Honestly. I can ignore it.'' This is ''not'' a winning strategy for solid code. In fact, it's just plain laziness. (The wrong sort.) No matter how unlikely you think an error is in your code, you should always check for it, and always handle it. Every time. You're not saving time if you don't: you're storing up potential problems for the future.

	We report errors in our code in a number of ways, including:		We report errors in our code in a number of ways, including:
-	* '''Return codes'''~~. A function returns a~~ value~~. Some~~ of ~~which~~ mean "it didn't work". Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from printf?	+	* '''Return codes''' can be used as the resulting value of a function to mean "it didn't work". Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from <code>printf</code>?
-	* '''errno''' ~~This~~ is a curious C ~~language~~ aberration, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems - for example, what happens when you have multiple threads calling the same function?	+	* '''errno''' is a curious C aberration, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems — for example, what happens when you have multiple threads calling the same function?
	* '''Exceptions''' are a more structured language-supported way of signaling and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this:		* '''Exceptions''' are a more structured language-supported way of signaling and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this:

Line 24:		Line 24:

	Not handling errors leads to:		Not handling errors leads to:
-	* '''Brittle code''', ~~full of~~ hard-to-find ~~crashes~~.	+	* '''Brittle code'''. Code that's filled with exciting, hard-to-find bugs.
	* '''Insecure code'''. Crackers often exploit poor error handling to break into software systems.		* '''Insecure code'''. Crackers often exploit poor error handling to break into software systems.
-	* '''Bad structure'''. If there are errors from your code that are tedious to deal with continually, you have probably have a ~~bad~~ interface. Express it ~~better,~~ so the errors are ~~not so~~ onerous.	+	* '''Bad structure'''. If there are errors from your code that are tedious to deal with continually, you have probably have a poor interface. Express it so that the errors are less intrusive and the their handling is less onerous.

-	Just as you should check all potential errors in your code, you ~~must~~ expose all potentially erroneous conditions in your interfaces. Do not hide them, ~~and pretend~~ that your services will always work.	+	Just as you should check all potential errors in your code, you need to expose all potentially erroneous conditions in your interfaces. Do not hide them, pretending that your services will always work.

-	Why don't we check for errors? There are a number of common excuses. Which of these do you agree with? How you would you counter each ~~of them~~?	+	Why don't we check for errors? There are a number of common excuses. Which of these do you agree with? How you would you counter each one?
-	* Error handling clutters up the flow of the code, making harder to read, and harder to spot the "normal" flow of execution.	+	* Error handling clutters up the flow of the code, making it harder to read, and harder to spot the "normal" flow of execution.
	* It's extra work and I have a deadline looming.		* It's extra work and I have a deadline looming.
-	* I know that this function call will '''never''' return an error (printf always works, malloc always returns new memory~~, and~~ if it fails we have bigger problems...)	+	* I know that this function call will '''never''' return an error (<code>printf</code> always works, <code>malloc</code> always returns new memory — if it fails we have bigger problems...).
	* It's only a toy program, and needn't be written to a production-worthy level.		* It's only a toy program, and needn't be written to a production-worthy level.
		+
		+	By [[Pete Goodliffe]]
		+
		+
		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page