Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > error handling: two flavors?

Reply
Thread Tools

error handling: two flavors?

 
 
Grary Stimon
Guest
Posts: n/a
 
      10-26-2010
Hi,

I recall reading somewhere (can't remember where) that there are two
flavors of error handling available in ruby: 1) for truly unexpected
contingencies, and 2) for other infrequent but expected contingencies.

So, I expect a method to return a value, including nil. But
if the method cannot return a value, including nil, i want it to return
a result along the lines of 2), above. it's not that i didn't anticipate
the case that my method might not be able to return a value, including
nil, rather, if it can't then i need to know based on some indicator
other
than nil, which is a meaningful value for my method!

can anyone refresh me on whether there are these two flavors of error
handling in ruby?

Grar

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
 
Cliff Phiri
Guest
Posts: n/a
 
      10-26-2010
[Note: parts of this message were removed to make it a legal post.]

Stop
On Tue, Oct 26, 2010 at 7:54 AM, Grary Stimon <(E-Mail Removed)>wrote:

> Hi,
>
> I recall reading somewhere (can't remember where) that there are two
> flavors of error handling available in ruby: 1) for truly unexpected
> contingencies, and 2) for other infrequent but expected contingencies.
>
> So, I expect a method to return a value, including nil. But
> if the method cannot return a value, including nil, i want it to return
> a result along the lines of 2), above. it's not that i didn't anticipate
> the case that my method might not be able to return a value, including
> nil, rather, if it can't then i need to know based on some indicator
> other
> than nil, which is a meaningful value for my method!
>
> can anyone refresh me on whether there are these two flavors of error
> handling in ruby?
>
> Grar
>
> --
> Posted via http://www.ruby-forum.com/.
>
>


 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      10-26-2010
On 26.10.2010 16:54, Grary Stimon wrote:
> I recall reading somewhere (can't remember where) that there are two
> flavors of error handling available in ruby: 1) for truly unexpected
> contingencies, and 2) for other infrequent but expected contingencies.
>
> So, I expect a method to return a value, including nil. But
> if the method cannot return a value, including nil, i want it to return
> a result along the lines of 2), above. it's not that i didn't anticipate
> the case that my method might not be able to return a value, including
> nil, rather, if it can't then i need to know based on some indicator
> other
> than nil, which is a meaningful value for my method!


It is generally not a good idea to use return values for error reporting
in a language that supports Exceptions. Numerous articles have been
written on this on the web. So for error reporting you better use
exceptions.

Returning nil from a method like Enumerable#find is a different story
because not finding anything is a completely expected outcome of a
search operation.

> can anyone refresh me on whether there are these two flavors of error
> handling in ruby?


Do you mean the distinction between exceptions inheriting StandardError
and others?

irb(main):001:0> begin
irb(main):002:1* Object.new.foo
irb(main):003:1> rescue => e
irb(main):004:1> puts "Caught #{e}"
irb(main):005:1> end
Caught undefined method `foo' for #<Object:0x1055a754>
=> nil
irb(main):006:0> begin
irb(main):007:1* raise ScriptError, "won't be caught"
irb(main):008:1> rescue => e
irb(main):009:1> puts "Caught #{e}"
irb(main):010:1> end
ScriptError: won't be caught
from (irb):7
from /usr/local/bin/irb19:12:in `<main>'

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
Grary Stimon
Guest
Posts: n/a
 
      10-26-2010
Robert,

Yes, my method would be like find, except I envisioned using a special
class of error to account for the case that #find cannot get the
'finder', which, itself, could report nil in the case that the object
sought did not exist. my thinking was that the finder might well not be
available, so that case was not truly 'exceptional', whereas if the
finder were available, but maybe improperly initialized, then that would
be exceptional, etc. my special class of error would save me from
multiple return values, e.g., [nil, nil].

I guess I can capture my meaning by defining a error specific to my
concern.

I was just puzzled, because I thought I read (not at
http://ruby-doc.org/docs/ProgrammingRuby/html/tut_...) that this had a
special approach associated with it (one different, say, from Java).

Thanks,

Grar

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      10-27-2010
On Tue, Oct 26, 2010 at 6:48 PM, Grary Stimon <(E-Mail Removed)> wrote:
> Yes, my method would be like find, except I envisioned using a special
> class of error to account for the case that #find cannot get the
> 'finder', which, itself, could report nil in the case that the object
> sought did not exist. my thinking was that the finder might well not be
> available, so that case was not truly 'exceptional',


On first sight I would consider this exceptional. Your description
sounds as if this is a two step approach:

fnd = obtain_finder
result = fnd.find_all

Now there seem to be mainly two reasonable ways to do this:

1. one method, with exception

1a)

# may return nil if there is no finder
def obtain_finder
...
end

def find_something
fnd = obtain_finder or raise "Cannot obtain finder!"
return fnd.find_all
end

or

1b)

def obtain_finder
raise "Cannot obtain finder!" if some_condition
return the_finder
end

def find_something
return obtain_finder.find_all
end

Use

begin
x.find_something
rescue => e
$stderr.puts "Sorry, cannot search because of #{e.message}."
end

2. two methods

# may return nil if there is no finder
def obtain_finder
...
end

class Finder
def find_all
...
end
end

Use:

f = obtain_finder
if f
f.find_all
else
$stderr.puts "Sorry, cannot search."
# or other reaction
end

My preference would be 1b because in this case the exception raised
from obtain_finder can include the reason for the error.

> whereas if the
> finder were available, but maybe improperly initialized, then that would
> be exceptional, etc. my special class of error would save me from
> multiple return values, e.g., [nil, nil].
>
> I guess I can capture my meaning by defining a error specific to my
> concern.


If you mean "defining an _exception_" then yes, probably.

> I was just puzzled, because I thought I read (not at
> http://ruby-doc.org/docs/ProgrammingRuby/html/tut_...) that this had a
> special approach associated with it (one different, say, from Java).


I have no idea what you are referring to. Of course, Ruby != Java,
but the main difference with regard to error handling is the fact that
Ruby does not have checked exceptions - while it has the distinction
between StandardError and not. And exception hierarchies are built
differently of course.

Cheers

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(8-bit binary to two digit bcd) or (8-bit binary to two digit seven segment) Fangs VHDL 3 10-26-2008 06:41 AM
How to compare two SOAP Envelope or two Document or two XML files GenxLogic Java 3 12-06-2006 08:41 PM
Error Description: ORA-03106: fatal two-task communication protocol error Vivek N ASP .Net 0 08-16-2006 01:16 PM
Two ISP -Two Routers - 1 PIX James Parks Cisco 5 12-11-2003 08:55 PM
Cisco 2611 with Two T1 from two ISPs Adam Embrey Cisco 3 07-24-2003 10:22 PM



Advertisments