An isconvertible check

[ViralBShah]

Working with real world data, it is common to encounter poorly formatted files and such. One thing I find myself frequently doing is something like this in DataFrames:

julia> int(df["Age"])
ERROR: ArgumentError("'F' is not a valid digit (in \"F\")")
 in parseint at string.jl:1209
 in int at string.jl:1242
 in map_to2 at abstractarray.jl:1450
 in map at abstractarray.jl:1459
 in int at /Users/viral/.julia/DataFrames/src/dataarray.jl:746

The Age column should been integers, but there is some bad data in the column, as a result of which readtable left the column as a string. When I try to use int, it is obvious that the data is corrupt, but I have no idea where it is corrupt.

I often find myself doing something like:

[ try int(df["Age"][i]) catch end for i in 1:nrow(df) ]

I think that an isconvertible function would be generally useful, which takes the same arguments as convert, but returns a boolean based on whether the conversion is possible or not.

[johnmyleswhite]

This would be great. I feel like this even came when I last wrote about the type inference code for DataFrames IO.

Jeff's response, which was quite correct, was that it's generally easier to try the conversion and only report if it failed. In DataFrames IO, you'll see that we now do exactly that by always returning a triple: (1) converted value, (2) did conversion succeed, (3) was value missing.

[ViralBShah]

Trying the conversion and reporting if it failed is also ok - and may end up being higher performance too. I am open to other ideas too, but I feel like this is essential to have for most of the convert functions in Base.

[johnmyleswhite]

I totally agree. As I've said before, I think we need a lot more tools for type conversion in Base.

[JeffBezanson]

This would be nice. It is a tricky design problem though, since having separate isconvertible and convert duplicates logic, and is potentially slow from doing almost the same work twice. convert is also extraordinarily performance sensitive.

[vtjnash]

with eventual debugging support, we should be able to read the frame info and pop the arguments out of their stack locations. although that would require being able to do that rather expensive operation in before unwinding the stack for the exception handler

perhaps this can be closed by #9316 (comment) and Nullable{Float64}, etc?