Jeremy,
On Mon, Jun 9, 2014 at 10:22 AM, Jeremy Lee
wrote:
>> When you use match, the match must be exhaustive. That is, a match error
>> is thrown if the match fails.
>
> Ahh, right. That makes sense. Scala is applying its "strong typing" rules
> here instead of "no ceremony"... but isn't the id
On Sun, Jun 8, 2014 at 10:00 AM, Nick Pentreath
wrote:
> When you use match, the match must be exhaustive. That is, a match error
> is thrown if the match fails.
Ahh, right. That makes sense. Scala is applying its "strong typing" rules
here instead of "no ceremony"... but isn't the idea that t
>
> The solution is either to add a default case which does nothing, or
> probably better to add a .filter such that you filter out anything that's
> not a command before matching.
>
And you probably want to push down that filter into the cluster --
collecting all of the elements of an RDD only to
When you use match, the match must be exhaustive. That is, a match error is
thrown if the match fails.
That's why you usually handle the default case using "case _ => ..."
Here it looks like your taking the text of all statuses - which means not all
of them will be commands... Which means
A match clause needs to cover all the possibilities, and not matching
any regex is a distinct possibility. It's not really like 'switch'
because it requires this and I think that has benefits, like being
able to interpret a match as something with a type. I think it's all
in order, but it's more of
I shut down my first (working) cluster and brought up a fresh one... and
It's been a bit of a horror and I need to sleep now. Should I be worried
about these errors? Or did I just have the old log4j.config tuned so I
didn't see them?
I
14/06/08 16:32:52 ERROR scheduler.JobScheduler: Error running
