Why are kwargs printed in full in a MethodError?

Internals & Design Internals
1 
julia> f(a::Int; b = nothing) = a
f (generic function with 1 method)

julia> f(2.0, b = zeros(10))
ERROR: MethodError: no method matching f(::Float64; b=[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0])
Closest candidates are:
  f(::Int64; b) at REPL[1]:1
Stacktrace:
 [1] top-level scope
   @ REPL[2]:1

In this case, the error is not due to the value/type of b, and displaying unnecessary information may actually make it harder to locate the actual error. Maybe the value of b should only be printed if the error is due to a type-mismatch on it? In this case, however, a TypeError is raised, and the value isn’t displayed at all.

julia> h(a::Int; b::Float64 = 0.0) = a
h (generic function with 1 method)

julia> h(2, b = 4)
ERROR: TypeError: in keyword argument b, expected Float64, got a value of type Int64
Stacktrace:
 [1] top-level scope
   @ REPL[9]:1

So… maybe we don’t need to display the values of kwargs at all?

1 Like
2

I often find it helpful to see values in error messages. Deep in a call stack I’d have to invoke a debugger to see what’s going on. It can make it harder to read, too, as you say. It would be nice to have a way of expanding/hiding information in an error.

3

Unfortunately, with nested tuples of custom types that define their own multi-line show methods, displaying them can quickly get messy. In my real use case, I had a terminal full of 150+ lines of a keyword argument being displayed, that had nothing to do with the error that I had to resolve.

4

I also don’t understand the need to print the kwargs in full. It is done quite intentionally though if you look at the source.

Might be worth opening an issue for? At least to limit the output on tuple types etc.

5

I’ve opened an issue about this

1 Like