Way of indicating an error

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

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 ?


--
Damien Cassou

On 2/26/07, Damien Cassou <[hidden email]> 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

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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DST: Deadlock System Tables

> 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

On Feb 26, 2007, at 8:54 AM, Damien Cassou wrote:
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

+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.

_________________________________________________________________
Find a local pizza place, movie theater, and more….then map the best route!
http://maps.live.com/?icid=hmtag1&FORM=MGAC01

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 you’ll love. Compare products and save at MSN®
Shopping.
http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001MSN20A0701