Misleading code example in Mojo::Transaction::WebSocket for json event

[daleif]

In the documentation for Mojo::Transaction::WebSocket under json we see

$ws->on(json => sub ($ws, $json) {...});

The implementation uses j from Mojo::JSON which should return undef if JSON decoding fails.

But if the WS payload coming in is not parseable JSON the callback gives the error Too few arguments for subroutine or similar.

The issue does not seem to have anything to do with Mojo::Transaction::WebSocket but rather with j

Here is a test file that emulates the problem.

#!/usr/bin/perl
use Mojo::Base -strict,-signatures;
use Mojo::JSON qw/j/;
use Carp;

sub test ($name,$val) {}
sub test2 { return eval { croak "a" } }

test( n => undef );
test( n => j('{"test":"test"}'));
test( n => j('a') );
test( n => test2() );

this fails with too few arguments on the third and forth item. The method test2 emulates what j ends up doing.

I'm not 100% sure what is going wrong here. I'm just writing this to note that it is misleading for the documentation to state that users should use signatures on the json callback when this fails if the json data cannot be parsed by decode_json.

[daleif]

I'm guessing that this implementation for j

sub j {
  return encode_json($_[0]) if ref $_[0] eq 'ARRAY' || ref $_[0] eq 'HASH';
  return eval { decode_json($_[0]) } // undef;
}

might be safer, even if I cannot explain why return eval { decode_json($_[0]) } is not seen as undef upon decode_json failure.

[Grinnz]

The return value of eval is context sensitive, it's an empty list in list context. We should guard against that: return scalar eval

[daleif]

Of course, I'd forgotten about context sensitivity.

[kraih]

Yes, that looks like a bug, we shouldn't rely on context.

[Grinnz]

Context sensitivity issue addressed by #2052