Thanks so much for the solution. It worked, first time.
But... as a procedural guy trying to "get" this here new-fangled OO stuff:
File.open: why no close (but only when there's a good open)?
Where's the error processing?
I wound up trying an explicit open with begin, rescue, end; then trying to read the file in one fell swoop (is that right?), and closing it; then issuing the SQL statement (with its own begin, rescue, end)...
I'm sure there's a shorter, necessary-and-sufficient way.
···
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 16 November 2002 20:00, Ted wrote:
> It seems so simple, but eludes me.
> I'd like to read a small file containing an SQL query into a String
> variabl, then use the String variable in a PostgreSQL query.
> I have the query working with a an assignment statement; but reading
> in the SQL hasn't worked -- at least for the last 3 hours...
> I'd like to do it as one read, if possible.
With no associated block, open is a synonym for File::new. If the
optional code block is given, it will be passed file as an
argument, and the file will automatically be closed when the block
terminates. In this instance, File::open returns nil.
Thanks so much for the solution. It worked, first time.
But… as a procedural guy trying to “get” this here new-fangled OO stuff:
File.open: why no close (but only when there’s a good open)?
Where’s the error processing?
I wound up trying an explicit open with begin, rescue, end; then trying to
read the file in one fell swoop (is that right?), and closing it; then
issuing the SQL statement (with its own begin, rescue, end)…
I’m sure there’s a shorter, necessary-and-sufficient way.
I wound up trying an explicit open with begin, rescue, end; then trying to read the file in one fell swoop (is that right?), and closing it; then issuing the SQL statement (with its own begin, rescue, end)…
Well, if you can’t open the file, then you can’t read the file content
and you don’t need to close the file. If reading the SQL query from
the file fails, the you can’t issue SQL statement because you don’t
have the query.
Thus, it’s perfectly alright to put all those within one
begin-rescue-end (bre) block:
begin
File.open(“dfsf”){|f| query << f.readlines.to_s}
sqlStatement = query
dbh.execQuery(sqlStatemetn)
.
.
.
all other dbh-related activity
.
.
.
rescue Exception=>e
p e
end
Thus, you don’t need to do bre block everytime you do
something. Arrange things that depend on the previous result to be in
one bre block.
[synack@Evergreen] ocelot $ ri File.open
[…]
With no associated block, open is a synonym for File::new. If the
optional code block is given, it will be passed file as an
argument, and the file will automatically be closed when the block
terminates. In this instance, File::open returns nil.
Is that last sentence from ri and the Pickaxe actually true? If it is, I’m
trying to understand what it means - 'cause
data = File.open(“test.dat”, “r”) { |f| f.read }
seems to return the result from the block, rather than nil (which is really
useful for me!)
data = File.open(“test.dat”, “r”) { |f| f.read; [1, 2]}
p data # [1, 2]
Thanks! I’ve experienced comparable behavior in returning
values from the File.open block… which led to my question
about whether the statement in ri and Pickaxe about File.open
returning nil when a block is given, is correct?
It would seem not, but I didn’t want to rule out the possibility
I misunderstood what was meant by that sentence in Pickaxe…
Thanks! I've experienced comparable behavior in returning
values from the File.open block... which led to my question
about whether the statement in ri and Pickaxe about File.open
returning nil when a block is given, is correct?
Well, ruby make something like this (when it has a block)
file = File.open("test.dat", "r")
begin
yield file
ensure
close file
end
'begin' ... 'ensure' return the value of the last expression (yield in
this case) if it don't have an error