On Fri Jul 04 01:39:12 2008, mor...@casella.verplant.org wrote:
> Error messages caused by programmer's mistakes shouldn't include stack
> traces.
> 
> Rakudo r29047:
> ../../parrot perl6.pbc -e 'my Int $x; $x = "str"'
> Type check failed
> current instr.: 'parrot;Perl6Object;infix:=' pc 59
(src/gen_builtins.pir:52)
> called from Sub '_block11' pc 93 (EVAL_12:42)
> called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806
> (src/PCT/HLLCompiler.pir:481)
> called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1305
> (src/PCT/HLLCompiler.pir:708)
> called from Sub 'parrot;Perl6::Compiler;main' pc 13152 (perl6.pir:174)
> 
> IMHO the stack trace is mostly unnecessary line noise, and shouldn't be
> visible to the programmer, since it obscures the real error message
> (which could be improved ;-)
> 
All stack trace into the compiler guts is now not shown at all now, and
that which is shown is at the sub/method level rather than exposing the
lexical scopes, and only has HLL line and file numbers in. In this
example the output is now just:

Type mismatch in assignment; expected something matching type Int but
got something of type Str()
in Main (<unknown>:1)

Thanks,

Jonathan

Reply via email to