From zefram@fysh.org

say "a"; "a" + 2; say "b"
a
"a" + 2
Cannot convert string to number​: base-10 number must begin with valid digits or '.' in '^a' (indicated by ^)
  in block <unit> at <unknown file> line 1

In both of these cases the addition signals an exception, terminating
the evaluation phase of the repl. But the exception is only reported in
the second case. The behaviour in the first case, with the exception
going unreported, is quite confusing in any case less obvious than
this example. The criterion determining whether the exception gets
reported is whether the evaluation has sent anything to the output stream.
This is obviously the same logic that's being used to suppress printing
the result of evaluation​: it's OK to suppress that, but silly to also
suppress error reports.

-zefram

From @zoffixznet

On Mon, 27 Feb 2017 00​:21​:17 -0800, zefram@​fysh.org wrote​:

say "a"; "a" + 2; say "b"
a
"a" + 2
Cannot convert string to number​: base-10 number must begin with valid
digits or '.' in '^a' (indicated by ^)
in block <unit> at <unknown file> line 1

In both of these cases the addition signals an exception, terminating
the evaluation phase of the repl. But the exception is only reported
in
the second case. The behaviour in the first case, with the exception
going unreported, is quite confusing in any case less obvious than
this example. The criterion determining whether the exception gets
reported is whether the evaluation has sent anything to the output
stream.
This is obviously the same logic that's being used to suppress
printing
the result of evaluation​: it's OK to suppress that, but silly to also
suppress error reports.

-zefram

Thank you for the report. This is now fixed.

Fix​: rakudo/rakudo@db70a1fda8
Tests​: rakudo/rakudo@db70a1fda8

The RT System itself - Status changed from 'new' to 'open'

@zoffixznet - Status changed from 'open' to 'resolved'

From zefram@fysh.org

Zoffix Znet via RT wrote​:

Fix​: rakudo/rakudo@db70a1fda8

This doesn't distinguish between an exception being thrown and the
expression evaluating to an exception object. The former is an error
condition that must be reported; the latter is a successful evaluation
in the same category as evaluating to a string. Incorrect behaviour
(failing to suppress output of a normal evaluation which produced its
own output) can be seen thus​:

say 123; try { my Int $a; $a = "foo" }; say 456; $!
123
456
Type check failed in assignment to $a; expected Int but got Str ("foo")
  in block <unit> at <unknown file> line 1

Your single $output variable is too narrow to make the distinctions that
you need.

-zefram

@zoffixznet - Status changed from 'resolved' to 'open'

From @zoffixznet

On Mon, 27 Feb 2017 14​:27​:04 -0800, zefram@​fysh.org wrote​:

Zoffix Znet via RT wrote​:

Fix​: rakudo/rakudo@db70a1fda8

This doesn't distinguish between an exception being thrown and the
expression evaluating to an exception object. The former is an error
condition that must be reported; the latter is a successful evaluation
in the same category as evaluating to a string. Incorrect behaviour
(failing to suppress output of a normal evaluation which produced its
own output) can be seen thus​:

say 123; try { my Int $a; $a = "foo" }; say 456; $!
123
456
Type check failed in assignment to $a; expected Int but got Str ("foo")
in block <unit> at <unknown file> line 1

Your single $output variable is too narrow to make the distinctions that
you need.

-zefram

Thanks for catching that one. Fixed now.

Fix​: rakudo/rakudo@61a65cee3d
Tests​: rakudo/rakudo@61a65cee3d

@zoffixznet - Status changed from 'open' to 'resolved'

From zefram@fysh.org

Zoffix Znet via RT wrote​:

Fix​: rakudo/rakudo@61a65cee3d

You've just moved the problem along. There's now a new class of
object that, if evaluated to, will be treated as if evaluation failed on
exception. Successful evaluation can yield literally any value, so if you
want to represent the disjunction of an evaluation result with something
that's not an evaluation result then you can't have evaluation results
just represented as themselves. That doesn't leave any distinct values
to represent the other things. You need more structure​: for example,
your single $output value could be a list of the form (True, $value)
to represent a normal evaluation result and (False, $ex) to represent
evaluation terminating by exception.

-zefram

@zoffixznet - Status changed from 'resolved' to 'open'

From @zoffixznet

On Mon, 27 Feb 2017 16​:53​:02 -0800, zefram@​fysh.org wrote​:

Zoffix Znet via RT wrote​:

Fix​: rakudo/rakudo@61a65cee3d

You've just moved the problem along. There's now a new class of
object that, if evaluated to, will be treated as if evaluation failed on
exception. Successful evaluation can yield literally any value, so if you
want to represent the disjunction of an evaluation result with something
that's not an evaluation result then you can't have evaluation results
just represented as themselves. That doesn't leave any distinct values
to represent the other things. You need more structure​: for example,
your single $output value could be a list of the form (True, $value)
to represent a normal evaluation result and (False, $ex) to represent
evaluation terminating by exception.

-zefram

Thanks. Fixed now. Note that your proposal wouldn't work, as
it's possible to fill out the exception variable by
returning a two-item Slip as the output.

Fix​: rakudo/rakudo@7f9235c79d
Tests​: rakudo/rakudo@7f9235c79d

@zoffixznet - Status changed from 'open' to 'resolved'