Post #199,286
3/17/05 5:57:25 PM
|
The difference is simple
Exceptions are a mechanism within the language which is supposed to be used to handle errors. Errors are cases of things going wrong. When you encounter an error, you can try to deal with it yourself, throw an exception, or return a value indicating that there is an error.
There is no ambiguity about what an exception is, it is a specific language construct. You either throw it or not.
There is a lot of ambiguity in figuring out whether something is really wrong. That's fully as hard as figuring out what it means for things to be OK.
As for figuring out whether to throw an exception or return an error, Jim's strategy is to either always throw an exception or always return an error - never mix and match. I'd agree with this philosophy. If there is doubt about whose job it is to handle errors, then errors are likely to get dropped on the floor.
Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #199,289
3/17/05 6:13:50 PM
|
Problem with that
"It's not an error. It's just a null response, meaning it didn't find anything." I hear it already.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #199,292
3/17/05 6:19:06 PM
|
See? Whether it is an error IS ambiguous!
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #199,296
3/17/05 6:28:16 PM
|
I think I know what to do then
My first instinct was to say you return errors or throw exceptions, but not both. I wasn't able to articulate a good reason for it though. But your formulation works for me: An exception is a language-specific mechanism for handling errors. If I start from that, there isn't any reason to use both interchangeably.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #199,300
3/17/05 6:59:56 PM
|
Exactly
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #199,332
3/17/05 11:59:18 PM
|
Re: Problem with that
"It's not an error. It's just a null response, meaning it didn't find anything."
If its not an error, then don't throw and exception. If it is an error, then do throw an exception.
You can't decide if something is an error until you know the purpose of the function you are writing. If the purpose is "Find the index", then not finding is an error. If the purpose is "Find the index if it exists", then not finding it is not an error.
Both choices make sense. Pick the one that makes sense to you at this moment. If you pick wrong, then let me tell you about a little thing called refactoring.
I remember working on a library that had open and close methods. I decided to make it an error to close an already closed connection (i.e. the purpose was "Close an open connection"). After writing some code using it, I discovered that it complicated my client logic testing to see if something was really open before attempting to close it. I changed the function to mean "Make sure the connection is closed", and the client code got significantly simpler.
--
-- Jim Weirich jim@weirichhouse.org [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #199,311
3/17/05 8:18:40 PM
|
Thats the sort of logic that makes me wary of exceptions.
Wary of exceptions as they are usually implemented, that is.
I like the failure model that SNOBOL and Icon use. They're a bit like miniature exceptions: if some function or operator doesn't have a value to return, it fails. Failure simply means "it didn't work". Catching it can be done explicitly with constructs like if and while, or implicitly which produces back-tracking and goal-directed evaluation (this should be familiar to RE wizards). If it isn't handled, it propagates upwards until it is or it can't go up anymore (letting something fail for the side-effects is a known programming technique in Icon). It removes the problem of "handling it elsewhere" that try/catch can produce.
OTOH, exceptions have some features that failure doesn't. The obvious one is that different types of exceptions can be raised. Failure is just failure. There are some system functions that have to fail when there's a problem; but you have to call another function to see how and why they failed.
(A less-obvious feature of exceptions is that they have much larger scope than failure. In Icon, failure is often bounded, so that a statement with an uncaught failure doesn't cause the language to backtrack farther than it should. This is by design. Exceptions have to play games with the stack as they propagate up until something catches them.)
Whether something is an error or not in a failure model is somewhat easier to answer: is there a value to return? No? Okay, fail*. As far as I can tell from this discussion, exceptions are *just* unwieldy enough that it actually becomes an issue as to whether a function, faced with a problem, should say "that's an error - throw an exception" or "no, that's not really an error - no exception needed." :-) Ouch.
Wade.
* To be fair, even Icon doesn't follow this slavishly. There are some - mainly graphcis - functions which return &null for one condition and "" for its opposite. It turns out that in actual usage, this is more versatile, particularly as there are operators to quickly and directly turn &null or not-&null into failure.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #199,323
3/17/05 10:33:45 PM
|
Exceptions are one form of Continuation
Icon's Generators are another form. And while we're tossing around various ways to cope with what amounts to problems in program continuity (errors, exceptions, whatever), I should also mention another way that's used to handle errors. Instead of using a setjmp/longjmp type mechanism of throwing/catching exceptions, why not just send a block of code that tells the function what to do in case of error? Of course, this requires lambdas or block closures. But it sends the code down into the place where the exception is easiest to handle (i.e. it is more specific). An example of this would be something akin to Smalltalk's onUnWind: type parameters.
|
Post #199,340
3/18/05 1:24:49 AM
|
Icon's generators rely on the failure model.
That's how you get back-tracking. :-)
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
