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

do not catch everything in isassigned #18075

Merged
merged 1 commit into from
Aug 17, 2016
Merged

do not catch everything in isassigned #18075

merged 1 commit into from
Aug 17, 2016

Conversation

KristofferC
Copy link
Sponsor Member

If getindex on an AbstractArray errors with ThrowMeOrEveryoneWillPerishOhMyGodTheyAreComingException we should probably throw it instead of just returning false in isassigned.

@nalimilan
Copy link
Member

Thanks, this was confusing when printing a broken custom array type gave lots of #undef entries instead of errors.

catch
false
catch e
if isa(e, BoundsError) || isa(e, UndefRefError)
Copy link
Sponsor Member

Choose a reason for hiding this comment

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

why BoundsError?

Copy link
Sponsor Member

Choose a reason for hiding this comment

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

ok, i didn't realize that worked:

julia> isassigned([], 2)
false

lgtm

Copy link
Sponsor Member Author

@KristofferC KristofferC Aug 17, 2016

Choose a reason for hiding this comment

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

But yeah, why not just use checkbounds for the bounds check part?

However, there doesn't seem to be anyway of checking if the field is undef without just trying to access it since that error is thrown from the runtime?

@KristofferC
Copy link
Sponsor Member Author

Because thats what the docs say.

@JeffBezanson JeffBezanson merged commit 0c45fa5 into master Aug 17, 2016
@tkelman tkelman deleted the kc/isassigned branch August 17, 2016 22:33
@tkelman
Copy link
Contributor

tkelman commented Aug 20, 2016

If you think this should be backported, do speak up.

@KristofferC
Copy link
Sponsor Member Author

Not sure. It is a behaviour change so probably shouldn't?

@KristofferC
Copy link
Sponsor Member Author

On the other hand it could be considered a bug fix since it now actually checks what the docs say it should check...

@StefanKarpinski StefanKarpinski added kind:bugfix This change fixes an existing bug backport pending 0.5 labels Aug 20, 2016
tkelman pushed a commit that referenced this pull request Aug 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:bugfix This change fixes an existing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants