[plt-scheme] escape handler gives error on escape continuation?

At Sat, 5 Feb 2005 22:10:31 -0600, Corey Sweeney wrote:
> can anyone tell me what this is about?  I registered a new escape
> handler to suppress read errors, to allow the process to continue
> rather then break to the scheme command prompt (i can gaurentee that
> all data from all possible read errors dosn't matter, as long as the
> process continues)

I take it that you don't want to use `with-handlers' for some reason?

> (define (guile-eval exp)
>   (define read-server
>     (lambda ()
>       (call/cc (lambda (c)
> ;      (call/ec (lambda (c)                 
>                  (error-escape-handler (lambda () (c #f)))
>                  (read server-input)))))
> 
> but i get:
> 
> read: bad syntax `#<'
> exception raised by error escape handler: continuation application:
> attempted to cross a continuation barrier; original exception raised:
> read: bad syntax `#<'

[I think you got the error messages backwards in your message. I've
reversed them.]

Normal continuations can't be used to escape from an exception handler.
This constraint is partly due to the way that exceptions are
implemented in the virtual machine.

> Also, this way:
> 
> (define (guile-eval exp)
>   (define read-server
>     (lambda ()
> ;      (call/cc (lambda (c)
>       (call/ec (lambda (c)                 
>                  (error-escape-handler (lambda () (c #f)))
>                  (read server-input)))))
> 
> i get:
> 
> read: bad syntax `#<'
> exception raised by error escape handler: continuation application:
> attempt to jump into an escape continuation; original exception
> raised: read: bad syntax `#<'

For this one, it's more difficult to tell without a complete program,
but maybe using `parameterize' as

 (parameterize ([error-escape-handler (lambda () (c #f))])
   (read server-input))

instead of an implicit `begin' would fix the problem.

Matthew