91 lines
3.7 KiB
Markdown
91 lines
3.7 KiB
Markdown
---
|
||
created_at: '2013-09-01T14:45:18.000Z'
|
||
title: Exceptions (2003)
|
||
url: http://www.joelonsoftware.com/items/2003/10/13.html
|
||
author: abl
|
||
points: 61
|
||
story_text: ''
|
||
comment_text:
|
||
num_comments: 90
|
||
story_id:
|
||
story_title:
|
||
story_url:
|
||
parent_id:
|
||
created_at_i: 1378046718
|
||
_tags:
|
||
- story
|
||
- author_abl
|
||
- story_6310555
|
||
objectID: '6310555'
|
||
year: 2003
|
||
|
||
---
|
||
**Exceptions**
|
||
|
||
People have asked why I don’t like programming with exceptions. In both
|
||
Java and C++, my policy is:
|
||
|
||
1. Never throw an exception of my own
|
||
2. Always catch any possible exception that might be thrown by a
|
||
library I’m using on the same line as it is thrown and deal with it
|
||
immediately.
|
||
|
||
The reasoning is that I consider exceptions to be no better than
|
||
“goto’s”, [considered harmful](http://www.acm.org/classics/oct95/)
|
||
since the 1960s, in that they create an abrupt jump from one point of
|
||
code to another. In fact they are significantly worse than goto’s:
|
||
|
||
1. **They are invisible in the source code.** Looking at a block of
|
||
code, including functions which may or may not throw exceptions,
|
||
there is no way to see which exceptions might be thrown and from
|
||
where. This means that even careful code inspection doesn’t reveal
|
||
potential bugs.
|
||
2. **They create too many possible exit points** for a function. To
|
||
write correct code, you really have to think about every possible
|
||
code path through your function. Every time you call a function that
|
||
can raise an exception and don’t catch it on the spot, you create
|
||
opportunities for surprise bugs caused by functions that terminated
|
||
abruptly, leaving data in an inconsistent state, or other code paths
|
||
that you didn’t think about.
|
||
|
||
A better alternative is to have your functions return error values when
|
||
things go wrong, and to deal with these explicitly, no matter how
|
||
verbose it might be. It is true that what should be a simple 3 line
|
||
program often blossoms to 48 lines when you put in good error checking,
|
||
but that’s life, and papering it over with exceptions does not make your
|
||
program more robust. I think the reason programmers in C/C++/Java style
|
||
languages have been attracted to exceptions is simply because the syntax
|
||
does not have a concise way to call a function that returns multiple
|
||
values, so it’s hard to write a function that either produces a return
|
||
value or returns an error. (The only languages I have used extensively
|
||
that do let you return multiple values nicely are ML and Haskell.) In
|
||
C/C++/Java style languages one way you can handle errors is to use the
|
||
real return value for a result status, and if you have anything you want
|
||
to return, use an OUT parameter to do that. This has the unforunate side
|
||
effect of making it impossible to nest function calls, so **result =
|
||
f(g(x))** must become:
|
||
|
||
> T tmp;
|
||
> if (ERROR == g(x, tmp))
|
||
> errorhandling;
|
||
> if (ERROR == f(tmp, result))
|
||
> errorhandling;
|
||
|
||
This is ugly and annoying but it’s better than getting magic unexpected
|
||
gotos sprinkled throughout your code at unpredictable places.
|
||
|
||
**PHP**
|
||
|
||
If someone wants to write up a nice article about how to develop
|
||
multilingual, Unicode applications with PHP or point me to an existing
|
||
article on the subject I will link to it here. Right now both the PHP
|
||
documentation and a google search for “PHP Unicode” make it look like
|
||
you’re pretty screwed if you really want to do Unicode in PHP. There is
|
||
[some existing
|
||
documention](http://ca3.php.net/manual/en/ref.mbstring.php) of mb\_
|
||
functions that people have pointed me to, which is badly written and
|
||
confusing, and appears to only support a handful of encodings, not
|
||
Unicode in general. It also seems to be an extension that you have to
|
||
turn on, which means, I think, that the average PHP installation does
|
||
not support this out of the box.
|