Hi all rubyists,
I apologize if my question irritates you. Now, for the last time, I use the
following code to explain why I looked for “resume next” in ruby initially.
First, I fully agree:
- Exceptions are better dealt locally.
- There are no generic error handler.
I would also say that most exceptions we encountered in program are
"expected" exceptions, for example, “file not found”, "connection broken"
etc. A really unexpected exception usally means a bug in the software, or
something really weird happened. Under such case, their are not much
difference if you catch/resue that or not. Keep that in mind, let’s read the
following code:
example 1: with resume next.
on error resume next
conn=tcpserver.connect(remote)
if conn==nil then
#some problem with connection
exit
end
f=File.open(testfile)
if f.class!=File then
#cannot open file
#do something with it
end
normal processing…
See in the above code, error handling are in normal code, the "resume next"
clause is only used to prevent the system from intercept the exception. In
ruby, you might right some different, maybe better, code, but the key point
is same: the programmer needs to expect where a possible error will occur.
as far as I know, no language is clever enough to do that for you (including
ruby).
I admit that ruby’s error handling is different, and I got the answers. I
appreciate all the suggestions including “callcc” etc. However, that’s not
what I want. Thanks again for all helps.
Shannon
···
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Shannon – I recommend that you start putting spaces around your
symbols (e.g., f.class!=File COULD be interpreted as f.class! = File
and not f.class != File).
conn = tcpserver.connect(remote)
if conn==nil then
#some problem with connection
exit
end
conn = tcpserver.connect(remote) rescue conn = nil
if conn.nil? then
some problem with connection
exit
end
f=File.open(testfile)
if f.class!=File then
#cannot open file
#do something with it
end
f = File.open(testfile) rescue f = nil
if f.nil? then
cannot open file
do something with it
end
This form of rescue won’t work on all exception types, but it will
catch a good majority of them. You could also make it so that the
rescue calls a method and then checks $! (the global exception
object) to determine the exact response, but that only hides your
normal begin/rescue/end handling.
-austin
– Austin Ziegler, austin@halostatue.ca on 2002.12.06 at 08.11.34
···
On Fri, 6 Dec 2002 22:02:39 +0900, Shannon Fang wrote:
Shannon Fang wrote:
on error resume next
conn=tcpserver.connect(remote)
if conn==nil then
#some problem with connection
exit
end
f=File.open(testfile)
if f.class!=File then
#cannot open file
#do something with it
end
normal processing…
begin
conn=tcpserver.connect(remote)
rescue
#some problem with connection
exit
end
begin
f=File.open(testfile)
rescue
#cannot open file
#do something with it
end
normal processing…
Your example has 12 lines mine (excluding blanks) has 13. Whats the big
deal about not having an on error handler?
PS I’ve been a basic programmer on PCs, Minis (VAX) and Mainframes since
1984 and was greatfull to get away from such bad exception handlers as
you find in cheap basics. VAX Basic, now there was a good basic it had
real exception handlers like…
WHEN ERROR IN
conn=tcpserver.connect(remote)
USE
#some problem with connection
exit
END
WHEN ERROR IN
f=File.open(testfile)
USE
#cannot open file
#do something with it
END
normal processing…
So exception handlers like Ruby are hardly new (about 30 years old, give
or take).
conn = tcpserver.connect(remote) rescue conn = nil
[…]
f = File.open(testfile) rescue f = nil
austin, Austin, AUSTIN! Shame on you 
conn = tcpserver.connect(remote) rescue nil
f = File.open(testfile) rescue nil
I love Ruby!
Gavin
···
From: “Austin Ziegler” austin@halostatue.ca