Re: [Rd] isOpen on closed connections

From: <Mark.Bravington_at_csiro.au>
Date: Fri, 16 Nov 2007 08:52:52 +1100

I'd support a change, to having a closed-but-not-invalid status for a 'rw' connection, and to have a usable 'isOpen'. The suggestion of relying on user-code to always "housekeep" after calling 'close', eg by setting to NULL, seems a bit risky as a guideline for R as a whole (one can never tell what convention a different author's code might follow). And the 'myOpen' solution will work (I'm about to use it myself) but cumbersome if everyone has to do it. With things as they are, I can foresee a stream of "why does.../RTFM" emails...

Perhaps the more fundamental issue is whether 'getConnection' should actually throw an error.
I'm getting bitten by this in R 2.6.1-- I use 'getConnection' in an 'on.exit' statement (where I can't be sure of the state of the connection), and it's throwing an error instead of returning NULL as it used to (and as the documentation still states).

-- 
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS

ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
 


> -----Original Message-----
> From: r-devel-bounces_at_r-project.org
> [mailto:r-devel-bounces_at_r-project.org] On Behalf Of Roger D. Peng
> Sent: Thursday, 15 November 2007 11:48 PM
> To: Prof Brian Ripley
> Cc: R-devel mailing list
> Subject: Re: [Rd] isOpen on closed connections
>
> Upon further consideration, I realized there is a
> philosophical element here---if a connection is closed and
> hence does not exist, is it open?
>
> The practical issue for me is that when you do something like
>
> close(con)
>
> the 'con' object is still lying around and is essentially
> undefined. For example, if I do
>
> close(con)
> con <- "hello"
>
> then it seems logical to me that 'isOpen' would return an
> error. But it feels natural to me that a sequence like
>
> close(con)
> isOpen(con) ## FALSE?
>
> would not lead to an error. Perhaps my expectations are not
> reasonable and I'd appreciate being corrected.
>
> Given Brian's comment, one solution would be to allowing
> closing but not destroying connections at the R level (maybe
> via an option?), but that is a change in semantics and I'm
> not sure if this problem really comes up that much.
>
> -roger
>
> Prof Brian Ripley wrote:
> > I think the confusion here is over close(): that closes
> *and destroys*
> > a connection, so it no longer exists.
> >
> > isOpen applies to existing connections: you cannot close but not
> > destroy them at R level, but C code can (and does). You
> will see it
> > in use in the utils package.
> >
> >
> > On Wed, 14 Nov 2007, Seth Falcon wrote:
> >
> >> "Roger D. Peng" <rpeng_at_jhsph.edu> writes:
> >>
> >>> As far as I can tell, 'isOpen' cannot return FALSE in the
> case when
> >>> 'rw = ""'.
> >>> If the connection has already been closed by 'close' or
> some other
> >>> function, then isOpen will produce an error. The problem is that
> >>> when isOpen calls 'getConnection', the connection cannot be found
> >>> and 'getConnection'
> >>> produces an
> >>> error. The check to see if it is open is never actually done.
> >>
> >> I see this too with R-devel (r43376) {from Nov 6th}.
> >>
> >> con = file("example1", "w")
> >> isOpen(con)
> >>
> >> [1] TRUE
> >>
> >> showConnections()
> >>
> >> description class mode text isopen can read can write
> >> 3 "example1" "file" "w" "text" "opened" "no" "yes"
> >>
> >> close(con)
> >> isOpen(con)
> >>
> >> Error in isOpen(con) : invalid connection
> >>
> >> ## printing also fails
> >> con
> >> Error in summary.connection(x) : invalid connection
> >>
> >>> This came up in some code where I'm trying to clean up
> connections
> >>> after successfully opening them. The problem is that if I try to
> >>> close a connection that has already been closed, I get an error
> >>> (because 'getConnection'
> >>> cannot
> >>> find it). But then there's no way for me to find out if a
> >>> connection has already been closed. Perhaps there's another
> >>> approach I should be taking? The context is basically,
> >>>
> >>> con <- file("foo", "w")
> >>>
> >>> tryCatch({
> >>> ## Do stuff that might fail
> >>> writeLines(stuff, con)
> >>> close(con)
> >>>
> >>> file.copy("foo", "bar")
> >>> }, finally = {
> >>> close(con)
> >>> })
> >>
> >> This doesn't address isOpen, but why do you have the call to close
> >> inside the tryCatch block? Isn't the idea that finally
> will always
> >> be run and so you can be reasonably sure that close gets
> called once?
> >>
> >> If your real world code is more complicated, perhaps you
> can make use
> >> of a work around like:
> >>
> >> myIsOpen = function(con) tryCatch(isOpen(con), error=function(e)
> >> FALSE)
> >>
> >> You could do similar with myClose and "close" a connection as many
> >> times as you'd like :-)
> >>
> >> + seth
> >>
> >>
> >
>
> --
> Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
>
> ______________________________________________
> R-devel_at_r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
______________________________________________ R-devel_at_r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Thu 15 Nov 2007 - 21:57:06 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 16 Nov 2007 - 00:30:28 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.