Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make apply_type error messages more understandable #12805

Closed
wants to merge 1 commit into from

Conversation

vtjnash
Copy link
Sponsor Member

@vtjnash vtjnash commented Aug 25, 2015

the current apply_type error message assumes the user knows that Type{...} expressions translate into calls to apply_type. This change is intended to make the error messages both more informative (more specific to the error) and more easily comprehended to those uninitiated with the bowels of the julia src code.

@kshyatt kshyatt added the error handling Handling of exceptions by Julia or the user label Aug 25, 2015
@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Aug 27, 2015

anyone care to comment on this, or should I just merge it and let people try it out

else if (!jl_is_datatype(args[0])) {
JL_TYPECHK(instantiate_type, typector, args[0]);
else if (!jl_is_datatype(args[0]) && !jl_is_typector(args[0])) {
jl_type_error("Type{...} expression", (jl_value_t*)jl_type_type, args[0]);
Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose this could be confused with a literal Type{ }.

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was actually the hardest one to write for that reason.

Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it's ok for now; I can't think of anything better so far.

@JeffBezanson
Copy link
Sponsor Member

It's good for a PR like this to have examples of the old and new output, so it's very quick to judge whether the new output is nicer. Looks OK to me so far.

@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Aug 27, 2015

side-comment: did you intend for Tuple types to be constructable with anything (except Vararg) inside?
e.g: Tuple{""}

@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Aug 27, 2015

Old:

julia> Vector{""}
ERROR: TypeError: apply_type: in alias, expected Type{T}, got ASCIIString

julia> Union{""}
ERROR: TypeError: apply_type: in parameter of Union, expected Type{T}, got ASCIIString

julia> Array{""}
ERROR: TypeError: apply_type: in Array, expected Type{T}, got ASCIIString

julia> Tuple{Vararg{()}, 1}
ERROR: TypeError: apply_type: in parameter of Tuple, expected Type{T}, got Type{Vararg{()}}

julia> ""{}
ERROR: TypeError: instantiate_type: expected TypeConstructor, got ASCIIString

julia> NTuple{""}
ERROR: TypeError: apply_type: in NTuple, expected Type{T}, got ASCIIString

julia> NTuple{1.2}
ERROR: TypeError: apply_type: in first parameter of NTuple, expected Int64, got Float64

@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Aug 27, 2015

New:

julia> Vector{""}
ERROR: TypeError: typealias: in parameter 1, expected Array{T,1}, got ASCIIString

julia> Union{""}
ERROR: TypeError: Union{...} expression: in parameter 1, expected Type, got ASCIIString

julia> Array{""}
ERROR: TypeError: Array: in parameter 1, expected Array, got ASCIIString

julia> Tuple{Vararg{()}, 1}
ERROR: TypeError: Tuple{...} expression: in parameter 1, expected Type, got Type{Vararg{()}}

julia> ""{}
ERROR: TypeError: Type{...} expression: expected Type, got ASCIIString

julia> NTuple{""}
ERROR: TypeError: NTuple: in parameter 1, expected NTuple, got ASCIIString

julia> NTuple{1.2}
ERROR: TypeError: NTuple{T, N} expression: in first parameter of NTuple, expected Int64, got Float64

@ScottPJones
Copy link
Contributor

The error messages for Vector{""} and Array{""} don't seem correct to me, they are not consistent with the error message for Union{""}.
For Array{""}, I would have expected: ERROR: TypeError: Array: in parameter 1, expected Type, got ASCIIString. For Vector, it really would be nice not to confuse people with Array syntax that they didn't use, is there any way the error message could be something like:
ERROR: TypeError: typealias Vector: in parameter 1, expected Type, got ASCIIString?

@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Aug 27, 2015

Vector is the name of the variable, and is therefore not part of the expression passed to apply_type. the current template that can be filled in is TypeError: <string>: in <string>, expected <Type>, got <typeof(value)>

@ScottPJones
Copy link
Contributor

But the expected needs to be Type, not Array{Type, 1}

@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Aug 27, 2015

The expected is for parameter 1 of Array{T,1} which is T and can be any isbits, Type, or Symbol

@JeffBezanson
Copy link
Sponsor Member

did you intend for Tuple types to be constructable with anything

No, that's a bug.

@JeffBezanson
Copy link
Sponsor Member

I don't think Array: in parameter 1, expected Array is right; it sounds like it expects an Array when it actually expects a Type.

@JeffBezanson
Copy link
Sponsor Member

Improved version of this on the way.

@ScottPJones
Copy link
Contributor

Bug part fixed?

JeffBezanson added a commit that referenced this pull request Sep 2, 2015
replaces #12805

- add error for Tuple{x} where x isn't a Type
- add error for invalid Tuple and Union types constructed via a
  parameterized typealias
- improve error messages
simonster added a commit to JuliaIO/JLD2.jl that referenced this pull request Sep 3, 2015
Don't encode on-disk representation information into types. Instead,
encode into a sequential ODRIndex{N}, which can be used by generated
functions to look up the on-disk representation.
@DilumAluthge DilumAluthge deleted the jn/apply_type_error_message branch March 25, 2021 22:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
error handling Handling of exceptions by Julia or the user
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants