[racket-dev] desired behavior of (in-directory …) when lacking permissions?

2012-08-31 Thread John Clements
Currently, using the (in-directory …) sequence in a directory where there are 
unreadable directories causes a funny internal contract failure.

Suppose I have directory /tmp/f, containing directory sekrit which I cannot 
read. Then this program:

#lang racket

(sequence-list (in-directory /tmp/f))

… produces this pair of errors:

. . plt/collects/racket/private/for.rkt:1857:28: directory-list: could not open 
directory
  path: /tmp/f/sekrit
  system error: Permission denied; errno=13
. . car: contract violation
  expected: pair?
  given: #void

The first one looks reasonable, but why wouldn't that error just abort the 
whole computation? It looks like there's a handler somewhere that eats this 
error but then tries to continue by passing #void rather than a list.

The docs don't seem to have anything to say about this.

Is this a bug?

John



smime.p7s
Description: S/MIME cryptographic signature
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] desired behavior of (in-directory …) when lacking permissions?

2012-08-31 Thread Matthew Flatt
At Fri, 31 Aug 2012 09:55:04 -0700, John Clements wrote:
 #lang racket
 
 (sequence-list (in-directory /tmp/f))
 
 … produces this pair of errors:
 
 . . plt/collects/racket/private/for.rkt:1857:28: directory-list: could not 
 open directory
   path: /tmp/f/sekrit
   system error: Permission denied; errno=13
 . . car: contract violation
   expected: pair?
   given: #void
 
 The first one looks reasonable, but why wouldn't that error just abort the 
 whole computation? It looks like there's a handler somewhere that eats this 
 error but then tries to continue by passing #void rather than a list.
 
 The docs don't seem to have anything to say about this.
 
 Is this a bug?

Yes.

The implementation of `in-directory' uses a prompt with the default
continuation prompt tag. It should use its own tag, instead, to avoid
interfering with error escapes. I'll push a repair.


_
  Racket Developers list:
  http://lists.racket-lang.org/dev