GNU bug report logs - #61658
30.0.50; server-eval-at might handle unreadable results better

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 61658 <at> debbugs.gnu.org
Subject: bug#61658: 30.0.50; server-eval-at might handle unreadable results better
Date: Wed, 22 Feb 2023 22:07:09 +0200

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 61658 <at> debbugs.gnu.org
> Date: Wed, 22 Feb 2023 10:28:05 -0700
> 
> >> I use server-eval-at to call a function, in another daemon, which
> >> returns a buffer.  So, server-eval-at tries (read "#<buffer *foo*>")
> >> which of course fails, and indeed signals an error.
> >>
> >> I wonder if server-eval-at should return a special value to indicate
> >> that the remote computation returned something that is not readably
> >> printable?  Or signal a particular error, which the caller might catch?
> >
> > Why can't you make that function return something more sensible?  Or
> > even just nil?
> 
> Yes, that is a way to handle cases like this.  I was thinking it might
> be better to have
> 
>     (define-error 'server-return-invalid-read-syntax
>                   "Remote function returned unreadable form"
>                   'invalid-read-syntax)
> 
> for a more flexible way to handle the situation.

But what we have now already gives you almost the same information:

  invalid-read-syntax, "#"

I'm not sure I understand what would the above add to this.  Is
"Remote function returned unreadable form" really that much more
informative, when the user doesn't expect an error?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.