Hi,
if a method should compute and return a value. If this method detects an error in its process what is the best way to indicate it:
- returning nil instead of the computed value - raise a specific error
Bye
Hi,
if a method should compute and return a value. If this method detects an error in its process what is the best way to indicate it:
- returning nil instead of the computed value
- raise a specific error
Bye
-- Damien Cassou
I like how detect works. If you don't pass a handler, raise an error
^#(John Doe) detect: [:each | each = 'Ramon'] => Error: Object is not in the collection
If you want to handle the error, don't catch it, make another method that takes the handler as an arg so the api is cleaner, so the client doesn't have to catch it.
^#(John Doe) detect: [:each | each = 'Ramon'] ifNone:['']
Then you can return nil via the handler if you like, or just handle the error some other way like returning an empty string, or don't pass a handler and let the exception propagate.
Ramon Leon http://onsmalltalk.com
I like how detect works. If you don't pass a handler, raise an error
^#(John Doe) detect: [:each | each = 'Ramon'] => Error: Object is not in the collection
If you want to handle the error, don't catch it, make another method that takes the handler as an arg so the api is cleaner, so the client doesn't have to catch it.
^#(John Doe) detect: [:each | each = 'Ramon'] ifNone:['']
Then you can return nil via the handler if you like, or just handle the error some other way like returning an empty string, or don't pass a handler and let the exception propagate.
This is exactely what I was thinking about. But, this is not that easy in my case because I'm working on reimplementing Streams.
Look at Stream>>next for example. It returns nil when there is no more element. Should I keep this behavior ? Should I implement Stream>>nextIfNoMore:.
Look at Stream>>next: now. This method returns a collection with the following x elements (x given as a parameter). If there is not enough element, the collection contains the last elements.
Would you think that a new Stream hierarchy should be more coherent and clearer, or do you think it should keep compatibility ?
On 26-Feb-07, at 8:23 AM, Damien Cassou wrote:
Would you think that a new Stream hierarchy should be more coherent and clearer, or do you think it should keep compatibility ?
If you are freshly implementing or completely re-implementing some capability you should do it in the way you believe to be correct.
I suggest that a part of working out what is correct is to see how you would use it and how you would explain it. If what you thought was correct turns out to be impossible to explain or cumbersome to use in code then there is a *really* good chance you weren't right about the design!
I can think of several ways of signalling an error a) return a special value - say nil - that has to be checked by user code b) set some variable that has to be checked by the user code c) signal an exception that has to be handled by user code d) use the pattern of passing in a block to be evaluated on an error #at:ifAbsent: etc e) exit the program as vigourously as possible - like VAXen used to do for divide by 0. :-)
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DST: Deadlock System Tables
+1. A lot of smalltalk things seem to be this way. Has a default (sometimes throw error, sometimes return nil), but allows the client to override the default easily.
From: "Ramon Leon" ramon.leon@allresnet.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "'The general-purpose Squeak developers list'"squeak-dev@lists.squeakfoundation.org Subject: RE: Way of indicating an error Date: Mon, 26 Feb 2007 09:09:58 -0700
Hi,
if a method should compute and return a value. If this method detects an error in its process what is the best way to indicate it:
- returning nil instead of the computed value
- raise a specific error
Bye
-- Damien Cassou
I like how detect works. If you don't pass a handler, raise an error
^#(John Doe) detect: [:each | each = 'Ramon'] => Error: Object is not in the collection
If you want to handle the error, don't catch it, make another method that takes the handler as an arg so the api is cleaner, so the client doesn't have to catch it.
^#(John Doe) detect: [:each | each = 'Ramon'] ifNone:['']
Then you can return nil via the handler if you like, or just handle the error some other way like returning an empty string, or don't pass a handler and let the exception propagate.
Ramon Leon http://onsmalltalk.com
_________________________________________________________________ Find a local pizza place, movie theater, and more .then map the best route! http://maps.live.com/?icid=hmtag1&FORM=MGAC01
On 2/26/07, Damien Cassou damien.cassou@gmail.com wrote:
if a method should compute and return a value. If this method detects an error in its process what is the best way to indicate it:
- returning nil instead of the computed value
- raise a specific error
By my philosophy, it depends upon the expected mindset of the caller. If the programmer who uses that method expects it to sometimes fail, the programmer expects to have to check the return value for suitability. But when a method nearly always succeeds, and a programmer might not want to have to deal with the rare failure, it's probably better to raise an error.
As an example, nearly every programming language handles "divide by zero" as an error (instead of returning nil or another unsuitable object). There are a few that return a NaN instead. Mostly, when a programmer codes a division operation, the programmer isn't expecting it to fail, so it's more natural to raise an error to catch that odd case.
But consider also how those same languages handle the problem of "item not found", whether it's not finding a substring in a larger string, an object in a collection, or a web resource. Nearly always, the programmer expects to check for the possibility that the item wasn't found, and so it's natural in those cases to return nil (or whatever) to say so. Only a few raise an exception when something isn't found. Smalltalk's common way of having an #...ifNotFound: block is another kind of exception handling.
That's not to say that this is a hard-and-fast rule. On the contrary, it's a matter of judgment, and there are many cases in which reasonable people may disagree. Fortunately, in a system like Squeak, it's easy to provide both methods that raise exceptions and ones that quietly return nil at the same time. That works for programmers of either mindset.
Hope this helps!
--Tom Phoenix
But consider also how those same languages handle the problem of "item not found", whether it's not finding a substring in a larger string, an object in a collection, or a web resource. Nearly always, the programmer expects to check for the possibility that the item wasn't found, and so it's natural in those cases to return nil (or whatever) to say so. Only a few raise an exception when something isn't found. Smalltalk's common way of having an #...ifNotFound: block is another kind of exception handling.
What would you expect from iterating over #(1 nil 2) ? The second #next will return nil. But it does not indicate the end of stream.
On Feb 26, 2007, at 8:54 AM, Damien Cassou wrote:
But consider also how those same languages handle the problem of "item not found", whether it's not finding a substring in a larger string, an object in a collection, or a web resource. Nearly always, the programmer expects to check for the possibility that the item wasn't found, and so it's natural in those cases to return nil (or whatever) to say so. Only a few raise an exception when something isn't found. Smalltalk's common way of having an #...ifNotFound: block is another kind of exception handling.
What would you expect from iterating over #(1 nil 2) ? The second #next will return nil. But it does not indicate the end of stream.
That reminds me, in Common Lisp, the stream object itself or some derived value could often be used as an end-of-stream marker since it is unlikely that a stream will contain itself (maybe a lazy stream would, but it doesn't cost *too* much to create a new lazy stream just to represent a continuation). Or, of course, you could make a special Exception type (which should note which stream has ended in case there is a nesting of stream exhaustions).
Have you also consulted Flow's Stream classes?
-- -Brian http://briantrice.com
From: "Damien Cassou" damien.cassou@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Way of indicating an error Date: Mon, 26 Feb 2007 17:54:53 +0100
But consider also how those same languages handle the problem of "item not found", whether it's not finding a substring in a larger string, an object in a collection, or a web resource. Nearly always, the programmer expects to check for the possibility that the item wasn't found, and so it's natural in those cases to return nil (or whatever) to say so. Only a few raise an exception when something isn't found. Smalltalk's common way of having an #...ifNotFound: block is another kind of exception handling.
What would you expect from iterating over #(1 nil 2) ? The second #next will return nil. But it does not indicate the end of stream.
-- Damien Cassou
Sounds easy then. If there is no suitable return value, then exceptions are the way to go. You might still provide #next:ifAtEnd: or some such in case the user has some other option.
_________________________________________________________________ Find what you need at prices youll love. Compare products and save at MSN® Shopping. http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001...
squeak-dev@lists.squeakfoundation.org
-
Brian Rice -
Damien Cassou -
J J -
Ramon Leon -
tim Rowledge -
Tom Phoenix