bug#61658: 30.0.50; server-eval-at might handle unreadable results better

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Sean Whitton]

Hello,

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?

-- 
Sean Whitton

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Mon, 20 Feb 2023 09:25:34 -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?

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Sean Whitton]

Hello,

On Mon 20 Feb 2023 at 07:09PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Date: Mon, 20 Feb 2023 09:25:34 -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.

-- 
Sean Whitton

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 61658@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?

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Sean Whitton]

Hello,

On Wed 22 Feb 2023 at 10:07PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: 61658@debbugs.gnu.org
>> Date: Wed, 22 Feb 2023 10:28:05 -0700
>> [...]
>> 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?

I'm thinking about the design of calling code, not errors that bubble up
all the way to the user.  If I want to catch this situation in calling
code, I can catch 'invalid-read-syntax'.  But for that to catch only the
errors I intend to catch, I have to assume that the only call to 'read'
in server-eval-at is the one that reads the remote daemon's output.  But
that's an implementation detail of server-eval-at, that could change.

-- 
Sean Whitton

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 61658@debbugs.gnu.org
> Date: Wed, 22 Feb 2023 17:24:26 -0700
> 
> Hello,
> 
> On Wed 22 Feb 2023 at 10:07PM +02, Eli Zaretskii wrote:
> 
> >> From: Sean Whitton <spwhitton@spwhitton.name>
> >> Cc: 61658@debbugs.gnu.org
> >> Date: Wed, 22 Feb 2023 10:28:05 -0700
> >> [...]
> >> 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?
> 
> I'm thinking about the design of calling code, not errors that bubble up
> all the way to the user.  If I want to catch this situation in calling
> code, I can catch 'invalid-read-syntax'.  But for that to catch only the
> errors I intend to catch, I have to assume that the only call to 'read'
> in server-eval-at is the one that reads the remote daemon's output.  But
> that's an implementation detail of server-eval-at, that could change.

So you want server.el to catch the error and re-throw it with a
different signal in this particular case?  Or am I misunderstanding?

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Sean Whitton]

Hello,

On Thu 23 Feb 2023 at 08:24AM +02, Eli Zaretskii wrote:

> So you want server.el to catch the error and re-throw it with a
> different signal in this particular case?  Or am I misunderstanding?

Yes, that's what I'd like to do.

-- 
Sean Whitton

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 61658@debbugs.gnu.org
> Date: Thu, 23 Feb 2023 10:27:11 -0700
> 
> On Thu 23 Feb 2023 at 08:24AM +02, Eli Zaretskii wrote:
> 
> > So you want server.el to catch the error and re-throw it with a
> > different signal in this particular case?  Or am I misunderstanding?
> 
> Yes, that's what I'd like to do.

But then just define-error isn't enough, is it?

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Sean Whitton]

Hello,

On Thu 23 Feb 2023 at 07:42PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: 61658@debbugs.gnu.org
>> Date: Thu, 23 Feb 2023 10:27:11 -0700
>>
>> On Thu 23 Feb 2023 at 08:24AM +02, Eli Zaretskii wrote:
>>
>> > So you want server.el to catch the error and re-throw it with a
>> > different signal in this particular case?  Or am I misunderstanding?
>>
>> Yes, that's what I'd like to do.
>
> But then just define-error isn't enough, is it?

Right.  I didn't mean to suggest it was -- my apologies.

-- 
Sean Whitton

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Sean Whitton]

Hello,

Now implemented.  Doesn't seem to me like a NEWS entry is warranted, but
if anyone strongly disagrees I can write one.

-- 
Sean Whitton

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Robert Pluim]

>>>>> On Wed, 08 Mar 2023 17:10:51 -0700, Sean Whitton <spwhitton@spwhitton.name> said:

    Sean> Hello,
    Sean> Now implemented.  Doesn't seem to me like a NEWS entry is warranted, but
    Sean> if anyone strongly disagrees I can write one.

It changes the possible behaviour of a public function, so I think it
is warranted (and I have some comments on the docstrings, but Iʼll
address those separately).

Robert
-- 

bug#61658: 30.0.50; server-eval-at might handle unreadable results better

[Sean Whitton]

Hello,

On Thu 09 Mar 2023 at 10:40AM +01, Robert Pluim wrote:

>>>>>> On Wed, 08 Mar 2023 17:10:51 -0700, Sean Whitton <spwhitton@spwhitton.name> said:
>
>     Sean> Hello,
>     Sean> Now implemented.  Doesn't seem to me like a NEWS entry is warranted, but
>     Sean> if anyone strongly disagrees I can write one.
>
> It changes the possible behaviour of a public function, so I think it
> is warranted (and I have some comments on the docstrings, but Iʼll
> address those separately).

But the new condition is a subtype of the old one, so it's a fully
backwards-compatible change to the behaviour.  Indeed, barely a change.
Does anyone else have any intuitions about this?

-- 
Sean Whitton