java.util.NoSuchElementException: None.get #218
Comments
|
Steps to reproduce: Relevant output: |
|
xuwei-k@a6066af4447db679f33 https://travis-ci.org/xuwei-k/scalaz/builds/108790554#L4764 |
|
cc @non A minimal way of reproducing this exception: So, if an arbitrary generator of the function's target type fails generating a value, this exception will be triggered. It is not obvious how we could work around this in the general case as long as generator results are modeled with the |
|
@rickynils I agree that using I have a branch where I removed [1] https://github.com/nick8325/quickcheck/blob/master/Test/QuickCheck/Gen.hs#L120 |
|
Hi All - I would really love to help out on this, but.... Anyway, any progress on this, as a fix for this would be useful to get into scalatest 3.0.0 release? |
|
Sorry for the long radio silence. I have thought I understood what was causing this particular crash several times. In fact, it's possible to fix @xuwei-k's branch with the following patch: |
|
I'm working on a patch to ScalaCheck to make this issue harder to hit. As @rickynils says, anytime someone is using The PR I'm working on is going to try to make invalid sizes and ranges throw errors, which makes it a lot easier to catch these kinds of problems. I also want to make some combinators to make it safer to use the size parameter. |
|
We could also choose to return |
non
pushed a commit
to non/scalacheck
that referenced
this issue
Aug 30, 2016
This commit was inspired by typelevel#218. It turns out that it ends up being very easy to accidentally create empty generators (that will never return Some(_) values) unnecessarily. The particular issue was around usage of Gen.sized, but there are a number of other combinators that end up creating empty generators in some cases. Previously, when the arguments to a combinator make it impossible to produce a value, ScalaCheck has preferred to produce empty Gen[T] values. After this change, combinators whose arguments make it impossible to generate values will instead throw exceptions during creation. This makes it easier for the author to realize and correct their mistake. The commit also tightens up a bunch of the internal logic around generating collections, numbers in a given range, etc. to minimize the use of empty generators. The reason why empty generators are a much bigger problem now than before is the introduction of Cogen[T]. When we produce an arbitrary `A => B` value, we do so by using a `Cogen[A]` to permute the PRNG, and then use a `Gen[B]` to produce a `B` value from that PRNG state. If our generator is empty (or even if it's a very sparse partial generator), this process will fail when we try to apply the function to an `A` value. Since ScalaCheck allows empty generators (as QuickCheck does) there's probably no backwards-compatible way to be 100% sure a `Gen[B]` is safe to use. However, in practice most `Gen` instances *could* be safe to use this way (as they are in QuickCheck), but are not due to how easy it is to end up with empty (or mostly empty) generators. This changes is binary compatible with the last release (check with MiMA). It does introduce new runtime behavior (in the form of some new exceptions users might see), but I think the change is worth it to get faster (and safer) generators, as well as more reliable function generators. Review by @rickynils, @xuwei-k, and anyone else interested.
non
pushed a commit
to non/scalacheck
that referenced
this issue
Aug 30, 2016
This commit was inspired by typelevel#218. It turns out that it ends up being very easy to accidentally create empty generators (that will never return Some(_) values) unnecessarily. The particular issue was around usage of Gen.sized, but there are a number of other combinators that end up creating empty generators in some cases. Previously, when the arguments to a combinator make it impossible to produce a value, ScalaCheck has preferred to produce empty Gen[T] values. After this change, combinators whose arguments make it impossible to generate values will instead throw exceptions during creation. This makes it easier for the author to realize and correct their mistake. The commit also tightens up a bunch of the internal logic around generating collections, numbers in a given range, etc. to minimize the use of empty generators. The reason why empty generators are a much bigger problem now than before is the introduction of Cogen[T]. When we produce an arbitrary `A => B` value, we do so by using a `Cogen[A]` to permute the PRNG, and then use a `Gen[B]` to produce a `B` value from that PRNG state. If our generator is empty (or even if it's a very sparse partial generator), this process will fail when we try to apply the function to an `A` value. Since ScalaCheck allows empty generators (as QuickCheck does) there's probably no backwards-compatible way to be 100% sure a `Gen[B]` is safe to use. However, in practice most `Gen` instances *could* be safe to use this way (as they are in QuickCheck), but are not due to how easy it is to end up with empty (or mostly empty) generators. This changes is binary compatible with the last release (check with MiMA). It does introduce new runtime behavior (in the form of some new exceptions users might see), but I think the change is worth it to get faster (and safer) generators, as well as more reliable function generators. Review by @rickynils, @xuwei-k, and anyone else interested.
|
I think this particular issue will be fixed by #258. The buggy generator in question would now crash earlier and signal to the author that there was a problem. |
|
Assume it's fixed? |
|
Closing as fixed. Please reopen if that is a mistaken assumption on my part. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
scalaz/scalaz#1095
The text was updated successfully, but these errors were encountered: