Error Handling: Separating from Code for Easier Maintenance

[0rthodontist]

Error handling obfuscates code. For someone reading your code, what your program does when there is an error is usually unimportant--at first they care only what it does when it works properly, and maybe later they'll come back to the errors, but understanding your error handling is a very low priority for someone reading your program. Furthermore it's ugly. Throwing a bunch of trys and catches into a neat, clean block of code completely ruins it, as well as probably tripling its length.

So what work has been done on separating error handling from code?

 

[chroot]

There's not a whole lot that can be done theoretically.

Some errors need to be detected and handled within the bowels of an otherwise very clean algorithm -- and the desire to maintain code locality means that that error-handling code needs to be inserted right there in the algorithm. You would not want it to be hidden in some separate file.

On the other hand, it's best to handle errors at the highest level possible. If you can allow exceptions to propagate out of entire blocks of code, you should.

There are only a couple of ways to really "separate" error handling code. Validation of arguments is a good way to clean things up -- put all your type- and bounds-checking up at the start of each block. The rest of your code can then tacitly assume no errors due to invalid inputs are possible. Also, contractual assertions can also be grouped together at the bottom of blocks of code. These contractual assertions pretty much just make sure the block above them did what it was intended to do.

Both of these techniques require a very good design skills, though; few people outside of academia really write their code with such foresight.

You might be interested in some of the "cleanroom" software engineering principles, which can be used to mathematically prove that code does what it's intended to do, and thus eliminates many of the possibilities of exceptions. They require a significant investment of labor, however.

- Warren

 

[NoTime]

Both of these techniques require a very good design skills, though;

Yes, I think what you said is a good overview.

few people outside of academia really write their code with such foresight.

If would be my experience that very few people fresh out of school address the problem at all, let alone "with foresight"

 

[Hurkyl]

So what work has been done on separating error handling from code?

You can always look at it as a presentation issue. Use an editor that let's you fold away things that you don't want to look at.

(Admittedly, I've been unhappy with what folding I've seen available, but I haven't explored them much. Maybe you should make a project to invent a good editor with useful folding ability. )

 

[-Job-]

You know, you can have multiple catches per try. :)
I actually like try/catch statements, they're better than checking for error conditions with if statements, for example.

 

[0rthodontist]

Yes, I was thinking along the lines of an editor feature. But some programmers prefer to work with plain text in a plain text editor--me not among them--so I was also wondering if anyone's done research on, maybe, applying an exception-handling "schema" to code that doesn't have error checking.

I once talked to someone who had the opinion that error handling should not be used as program control--that it should be used for only the things you can't detect otherwise, because of the overhead of throwing and catching an exception. At the time I disagreed, on the grounds that I'd rather write the "mainstream" of my code, then toss in some easy error handling for the cases where it doesn't work. I still believe, in regard to both exceptions and "unusual cases," that code should be written as if it worked and then patched for the cases where it doesn't work. But I think that the patch should be external--that someone should be able to read only the mainstream of your code, which gives them the gist of what it does, and only afterwards read what happens in special cases.

Also, thinking about this just now, separating special cases from "mainstream" code might help a programmer write the program, too. By separating special cases into a different section, it might enable the programmer to review the special cases as an entity all their own and decide whether any error is still unchecked more easily.

I think that a clue towards making something like that happen is finding ways to restrict what "special-case" or exception code should be able to do.

 

[chroot]

But I think that the patch should be external--that someone should be able to read only the mainstream of your code, which gives them the gist of what it does, and only afterwards read what happens in special cases.

This is a very bad idea. You generally want to promote code locality -- you want everything involved in a single task to be in the same place, where it can all be read together.

Besides, there are so many distinct ways that a complex piece of code can fail that separating the error handling in the fashion you desire would make it extremely difficult for a reader to piece it all together.

What you want -- a program without any kind of interwoven exception handling -- is a pipe dream. There are ways to hide or minimize the error handling, using editor features or design techniques like contracts. There are zero-defect techniques that can be used to formally prove that a piece of code has no exceptions which need to be handled -- but you want to be able to look at an arbitrary piece of complex code, written without the burden of formal verification -- without any of the "clutter" of error handling.

I think this is a pipe dream, because what truly separates a good programmer from an excellent programmer is his/her awareness of the failure modes of each line of code written. A programmer who intends to write a piece of code as if nothing can go wrong, and only later go in and "insert" error handling as an afterthought, is a poor programmer.

- Warren

 

[0rthodontist]

Nonsense--planning the main idea of your code first before writing the special cases is just another incarnation of top down design. It is a good idea to focus on the big picture before worrying about the details. This goes when you're writing code as well as when you're reading it. Why not reflect that as a language feature?

I agree that repeatedly referring to an outside section of code for exception handling is a bad idea. The challenge would be to make the syntax for an exception handling schema simple and clear enough so that you can read it once and don't often need to refer back to it, but powerful enough so that it can do the things it needs to do.

I don't believe that failure modes of a particular line of code is a high priority. It's certainly important, but it's secondary. Understanding how the code actually works, when it does work, is the essential step 1 for making or reading it. Surely you are not proposing that it is more important, on a first reading, to understand the 1% of the time when flawed code fails than the 99% when it works? Even if your goal is to fix the flawed code, do you really want to look at the failures before you understand how the program's even intended to run?

There is another advantage to separating exceptions and special cases from the mainstream code: doing so promotes the concept of exceptions and special cases. It creates a clear, abstract distinction between exceptions and special cases, and the main code. A change to code can then be looked at as either a "special case" alteration, or a "mainstream" alteration. Special cases tend to be local and trivial, and easier to change without affecting mainstream code. Mainstream code, being the actual design of the application, is much harder to change, and the programmer should be aware of which he is dealing with at a given time. Separating special cases introduces that abstraction.

 

[Hurkyl]

I posit that writing code is considerably more important than reading code.

 

[chroot]

I mean no offense, Orthodontist, but you're a student, right? It seems every student goes through a phase where they think they can design a better language...

- Warren

 

[Sane]

I don't understand where your issue with readability in error-handling applies. In the function, raising the error will be very clean, and actually provide insight into the limitations/restraints/and conditions of the procedure, hence more readable code.

On the other hand, in the implementation where some obfuscation may occur, as an error excepting handle appears for every function call... this all occurs to the extent of the programmer's needs. If it ever becomes obfuscated beyond the point of readability, either it's complicated enough to disregard the possibility of language-related syntactical anomalies, or the programmer who's implementing the functions is being redundant or over-protective of the performance of his code.

All in all, I think it's silly to be pestering about this.

 

[-Job-]

I agree with Sane on this.

 

[0rthodontist]

I`[/color]posit`[/color]that`[/color]writing`[/color]code`[/color]is`[/color]considerably`[/color]more`[/color]important`[/color]than`[/color]reading`[/color]code.

It`[/color]is`[/color]a`[/color]true`[/color]fact`[/color]that`[/color]most`[/color]programming`[/color]work`[/color]is`[/color]code`[/color]maintenance,`[/color]not`[/color]creation.

I`[/color]mean`[/color]no`[/color]offense,`[/color]Orthodontist,`[/color]but`[/color]you're`[/color]a`[/color]student,`[/color]right?`[/color]It`[/color]seems`[/color]every`[/color]student`[/color]goes`[/color]through`[/color]a`[/color]phase`[/color]where`[/color]they`[/color]think`[/color]they`[/color]can`[/color]design`[/color]a`[/color]better`[/color]language...

I`[/color]don't`[/color]think`[/color]it's`[/color]a`[/color]very`[/color]common`[/color]interest.`[/color]`[/color]Anyway`[/color]there`[/color]are`[/color]a`[/color]lot`[/color]of`[/color]languages,`[/color]and`[/color]a`[/color]lot`[/color]of`[/color]fairly`[/color]new`[/color]languages,`[/color]so`[/color]it's`[/color]not`[/color]an`[/color]unrealistic`[/color]goal.

Consider`[/color]the`[/color]following`[/color]function,`[/color]not`[/color]written`[/color]by`[/color]me:

        def`[/color]wget_link(self,url,flag,parent_url="",ignore_pr=False):
                """
                Download`[/color]url`[/color]and`[/color]all`[/color]requisite`[/color]pages
                First`[/color]Create`[/color]new`[/color]dir`[/color]or`[/color]use`[/color]old`[/color]parent`[/color]dir
                """
                dir=md5dir(self.subdir,url,parent_url)
                if`[/color]dir==None:
                        print`[/color]'md5dir`[/color]came`[/color]back`[/color]with`[/color]none!'
                        sys.exit()
                #print`[/color]"\twgetting`[/color]%s"`[/color]%`[/color]url

                #`[/color]Retrieval`[/color]of`[/color]images`[/color]from`[/color]yahoo`[/color]doesn't`[/color]use`[/color]the`[/color]printer`[/color]ready`[/color]flag,`[/color]html`[/color]does
                pr=self.printer_ready
                if`[/color]ignore_pr:
                        pr=''
                wget_command`[/color]=`[/color]('/usr/bin/wget`[/color]`[/color]-E`[/color]-nv`[/color]-H`[/color]-k`[/color]-p`[/color]%s`[/color]--no-host-directories`[/color]--no-directories`[/color]-P%s`[/color]\"%s%s\"'`[/color]%`[/color](flag,dir,url,pr))
                (status,output)=commands.getstatusoutput(wget_command)
                if`[/color](status>0):
                        self.pr`[/color]("Wget`[/color]failed!`[/color]\n\t%s"`[/color]%`[/color]output)
                        return()
                #`[/color]see`[/color]what`[/color]wget`[/color]renamed`[/color]the`[/color]file`[/color]as
                try:
                        link=output.split('`[/color]URL:')[1]
                        link=link.split('"')[1]
                        return(link)
                except:
                        self.pr`[/color]("WGET`[/color]ERROR:\ncommand:\n%s\nURL:%s\n--\n%s\n--\nCould`[/color]not`[/color]determine`[/color]new`[/color]wget`[/color]link:`[/color]%s"`[/color]%`[/color](wget_command,url,output,sys.exc_info()[0]))
                        return('')

Consider`[/color]its`[/color]equivalent`[/color]with`[/color]no`[/color]error`[/color]checking:

        def`[/color]wget_link(self,url,flag,parent_url="",ignore_pr=False):
                """
                Download`[/color]url`[/color]and`[/color]all`[/color]requisite`[/color]pages
                First`[/color]Create`[/color]new`[/color]dir`[/color]or`[/color]use`[/color]old`[/color]parent`[/color]dir
                """
                dir=md5dir(self.subdir,url,parent_url)

                #`[/color]Retrieval`[/color]of`[/color]images`[/color]from`[/color]yahoo`[/color]doesn't`[/color]use`[/color]the`[/color]printer`[/color]ready`[/color]flag,`[/color]html`[/color]does
                pr=self.printer_ready
                wget_command`[/color]=`[/color]('/usr/bin/wget`[/color]`[/color]-E`[/color]-nv`[/color]-H`[/color]-k`[/color]-p`[/color]%s`[/color]--no-host-directories`[/color]--no-directories`[/color]-P%s`[/color]\"%s%s\"'`[/color]%`[/color](flag,dir,url,pr))
                (status,output)=commands.getstatusoutput(wget_command)
                #`[/color]see`[/color]what`[/color]wget`[/color]renamed`[/color]the`[/color]file`[/color]as
                link=output.split('`[/color]URL:')[1]
                link=link.split('"')[1]
                return(link)

It's`[/color]clearer.`[/color]`[/color]Actually`[/color]the`[/color]essence`[/color]of`[/color]this`[/color]function`[/color]could`[/color]be`[/color]2`[/color]lines`[/color]without`[/color]error`[/color]checking`[/color]and`[/color]if`[/color]you`[/color]ask`[/color]the`[/color]caller`[/color]to`[/color]make`[/color]the`[/color]directory,`[/color]namely`[/color]just`[/color]a`[/color]wget`[/color]and`[/color]a`[/color]return`[/color]of`[/color]the`[/color]URL,`[/color]vastly`[/color]reducing`[/color]the`[/color]time`[/color]needed`[/color]to`[/color]figure`[/color]out`[/color]what`[/color]the`[/color]hell`[/color]is`[/color]going`[/color]on.`[/color]`[/color]Also`[/color]you`[/color]really`[/color]only`[/color]need`[/color]2`[/color]arguments,`[/color]dir`[/color]and`[/color]url,`[/color]not`[/color]4.

 

[0rthodontist]

Why can't I edit?

Edit: I mean, why can't I post any Python code?
Edit: I can if I replace the spaces with black-colored `'s...

 

[Sane]

Now yet again, you are splitting hairs ...

Focusing on that Python code you posted, that is a poor example to prove a point. The error handling is not filtering what kind of error it handles. Using the except command without any statement following it will direct any error to the excepted code block.

If the code were written properly, it would be clear and concise as to what error it's excepting and handling. This is definitely more readable. To think otherwise is either ignorant, or just plain silly.

 

[0rthodontist]

It would be a bit clearer if the type of the error were included, but that's not the main problem.

Consider this function:

	def retrieve (self):
		try:
			mod=self.current.modified
		except:
			mod=''

		self.new = feedparser.parse(self.url,modified=mod)
		try:
			if self.new.status == 304:
				self.pr ('\t304: no updates')
				return()
		except:
			self.pr('No status variable... no internet access?')
			self.new.status=304
			return()
		if self.new.bozo>0:
			self.pr('Failed to retrieve (proper) rss feed:\n\t%s' %
					(self.new.bozo_exception))

		if self.new.feed.has_key('lastbuilddate'):
			try:
				self.new.lbd = time.strptime(self.new.feed['lastbuilddate'],"%a, %d %b %Y %H:%M:%S %Z")
				self.pr('LBD of new feed %s' % (time.mktime(self.new.lbd)))
			except:
				pass
			else: 
				try:
					if time.mktime(self.current.lbd) == time.mktime(self.new.lbd):
						self.pr ('\tLBD unchanged %s==%s' % (time.mktime(self.current.lbd),time.mktime(self.new.lbd)))
						self.new.status=304
						return()
				except:
					self.pr ('\tNo LBD key in current: %s' % sys.exc_info()[0])
					
		#self.pr ('\tstatus: %d ' % self.new.status)
		self.pr ('\tEntries retrieved: %d' % len(self.new.entries))
		# number the entries for renaming the link in the updates subroutine
		ind=0
		for x in self.new.entries:
			x.index=ind
			ind+=1

Without error handling (and removing some extraneous code), this is one line (whited out so you can read the function as written first):
return feedparser.parse(self.url,modified=mod)[/color]
Is it easier to understand if you see that one line, or see all the error handling?

 

[chroot]

So... why doesn't the author just put that "one-liner" in his comments above the code? Then you know exactly what the "gist" of the block is -- that's what this is all about, right? -- and the error-handling code stays put, interwoven with the code it protects, as it should be.

And, besides, the code you pasted does NOT just download a page -- it checks server status codes, timestamps, and does other things. I agree it's poorly written code, but even without error-handling, it won't be just one line. You're being dishonest.

- Warren

 

[Sane]

In my opinion ...

The error handling is very important. It'll tell whoever's reading your code what crap not to throw its way. If you really feel like achieving a sense of readability, I'll tell you what...

At the top of the function, include a """ multiline comment """ that contains the code without error handling. Otherwise, your intentions in compromising length of code for a secure algorithm is unjustified.

Edit : Wow. A pleasant surprise: chroot and I both suggested the exact same thing. Comment yer "readable" code if it makes such a difference.

 

[chroot]

At the top of the function, include a """ multiline comment """ that contains the code without error handling. Otherwise, your intentions in compromising length of code for a secure algorithm is unjustified.

Bingo. That's two of us, who have independently said the same thing.

- Warren

 

[0rthodontist]

And, besides, the code you pasted does NOT just download a page -- it checks server status codes, timestamps, and does other things. I agree it's poorly written code, but even without error-handling, it won't be just one line. You're being dishonest.

No, it really is. There's no need to check the last build date because if there wasn't a 304, it will always be different. Also the index code doesn't actually do anything since the index already contains those values (not that you need them anyway since you can just iterate through the feeds). All the rest is just error handling--necessary, but obfuscating. Well, there's also the "mod" variable, but still the only reason you had to make that is because you didn't know if the current feed had a modified field, so its purpose is still entirely error handling.

 

[turbo]

I wrote custom specialty software for small businesses back in the day when a 286 was a potent machine and 386's were servers. I wrote code in modules that had specific functions, and commented them heavily, so that when I went to my library of modules, I didn't have to parse the code every time to remember what functions they performed. That way, when a customer had a complex problem, I could just scan my modules with a text editor and decide which ones to use, and which ones might be usable with minor modification. Error-handling was built into the modules and was commented.

Showing my age, I wrote these applications in Ashton-Tate dBase and as soon as FoxBase came out with a compiler, I compiled them to run under FoxRun. Pretty primitive, but it worked great. In this system, error -handling had to accompany the relevant code.

 

[Sane]

All the rest is just error handling--necessary, but obfuscating.

It's necessary, I'm happy you acknowledged that.

Your nested indentations of exceptions do lead to obfuscation, however it doesn't have to. The obfuscation lends itself to being the result of your programming. You don't state which errors to except, and you can turn the excepted blocks into methods in your class. That way you can label each resulting event of an error, respectively, with a function name. Additionally, you've limited your obfuscation to simple nesting.

It's quite simple really, but only worth it if you do really care that much (which, by the size of this thread, illustrates just that).

 

[chroot]

You must check the date, because some servers might be broken or non-compliant. Such servers might not return a 304, even when the dates are the same. The 304 status code is not even required by the HTTP/1.1 RFC -- it is simply suggested.

Do you really trust a server you didn't write, running on a computer you don't control? Do you really not feel that this is a justified thing to check?

It sounds to me like your gripe is really that people don't write (or comment) their code cleanly enough to make it easy for a novice reader to immediately understand what is being done in a block of code. The solution to this problem is better commenting and better conventions. The solution is absolutely not to split the error handling off to some other file where it can be "hidden." Error handling is an integral and necessary part of writing a decent program -- it is not just some dirty, menial task that has to be grudingly done after having written the "pristine" one-line version.

- Warren

 

[0rthodontist]

Why should a programmer have to remember to put shorter, exception-free code in a comment? It would feel like busywork, and nobody's going to do that. And nobody does. If it's useful, and if you think it should be in a comment then we agree that it is useful, it has to be a language feature.

It is not absolutely necessary to check the dates, because the worst that will happen is that the server (the one that's running this code) will spend an extra couple seconds writing stuff to disk that it already has. It is a slight efficiency optimization, not an issue of correctness (and remember that this is written in Python, which is very slow anyway). Now that I look at it again, the whole thing with making the "lbd" is actually unnecessary since you could have just compared self.current.lastbuilddate with self.new.lastbuilddate.

I certainly object to calling me a "novice" programmer. I'm not a novice programmer. Also, I certainly never suggested that the error handling should be in "some other file." It should be separate, but near.

 

[0rthodontist]

The obfuscation lends itself to being the result of your programming. You don't state which errors to except, and you can turn the excepted blocks into methods in your class. That way you can label each resulting event of an error, respectively, with a function name. Additionally, you've limited your obfuscation to simple nesting.

The examples of obfuscation are not my code.

 

[Bucky]

I will admit that code with no error handling is wonderful and clean and easy to read...but its also a nightmare to maintain and use.

Often error handling code can be streamlined into a single function call. Consider the following c++ (written on the fly, may not compile ;) )

void ErrorBox(char* message, bool instruction)
{
     MessageBox(NULL, NULL, &message, MB_OK);//Print error message box
if(instruction)//Quit program if true is passed, else continue
QuitProgram();
}

void MyFunction()
{
...
if(somethingsWentWrong) ErrorBox('File Not Found', true);   //Bail the app
}

(while i usualy hate a state check and action on one line, if its a commonly used one i feel its reasonable. ;) )

furthermore, i think error checking helps eliminate problems in debugging. if you have a 3d model that isn't being textured properly and you know that a texture has been loaded into memory, you can focus your attention to the other reasons that its not being textured.

 

[chroot]

Why should a programmer have to remember to put shorter, exception-free code in a comment? It would feel like busywork, and nobody's going to do that.

And having to add obvious decoration to a function prototype to say that it consumes input is busywork, and no one's going to do that either. Apparently, what most programmers would judge a needless burden, you would consider an incredibly important language feature. Potato, po-tah-to, yes?

It is not absolutely necessary to check the dates, because the worst that will happen is that the server (the one that's running this code) will spend an extra couple seconds writing stuff to disk that it already has.

I don't have the rest of the code for this program (whatever it is), but, by the looks of it, it'll probably list two different "versions" of the same RSS feed, with the same timestamp. It'll confuse the heck out of the user. Besides, if you ever decided to re-use this module for some other purpose, you (or your coworkers) will be very happy that you spent a few miniscule lines of code to compae the timestamp and make sure that the new version really is different from the previous, and didn't just decide to rely upon the often poorly-implemented HTTP RFC.

Assumptions -- like whether or not the user of this module is overwriting existing data, or is making a new list entry for every new version -- are the worst kind of evil in computer programming.

I certainly object to calling me a "novice" programmer. I'm not a novice programmer. Also, I certainly never suggested that the error handling should be in "some other file." It should be separate, but near.

I'm sorry, but the suggestion that programmers should break code locality in favor of some kind of aesthetic "code attractiveness" is a novice suggestion. In the real world, people don't care much about whether a function is a tidy one-liner or a half-page with a bunch of well-written error-handling; they care about whether or not it works, is re-usable, and is easy to read and maintain. No one's judging your code by its brevity in the real world. Separating error handling -- even just putting it into another area of the same file -- is by just about every criterion an awful idea.

- Warren

 

[Sane]

Apparently, what most programmers would judge a needless burden, you would consider an incredibly important language feature. Potato, po-tah-to, yes?

Brilliant! I'll have to remember that one.

Pretty much everything has been said by now. If I were to continue on with this "debate" any longer, we'd just keep seeing repeats of everyone's arguments.

This is going nowhere. I've said what I've had to say.

 

[haki]

Haha, funny.

 

[0rthodontist]

And having to add obvious decoration to a function prototype to say that it consumes input is busywork, and no one's going to do that either. Apparently, what most programmers would judge a needless burden, you would consider an incredibly important language feature. Potato, po-tah-to, yes?

Have you ever seen any programmer make use of this commenting style you are describing? If you're referring to the takes/alters syntax from another thread, I made it extremely clear that it would need to be automatically generated, and that in fact that was part of the point, so that it would provide documentation that a programmer might not have created on his own.

No time right now to reply to the rest.

 

[chroot]

Have you ever seen any programmer make use of this commenting style you are describing? If you're referring to the takes/alters syntax from another thread, I made it extremely clear that it would need to be automatically generated, and that in fact that was part of the point, so that it would provide documentation that a programmer might not have created on his own.

You're the one claiming that this coding style with "separated" error handling is superior to simply having the error-handling intermingled with the code it protects -- not me. I have never seen anyone besides you argue that this would be a good idea, so no, I have never seen anyone else do it.

- Warren

 

[0rthodontist]

Chroot, were you actually talking about the takes/alters syntax in the other thread as I thought in my last post?