Hmm. I’m not sure what the SO suggestion was getting at, but a MatchError generally means there’s a real bug in the program – you have an input to the match, with no case that handles it. I’d recommend taking a look at the code and making sure that you do actually handle (List(), None)…

Hi Jd, yes, this was my complaint. I indeed had a case missing (Nil, None) but the compiler didn’t warn me. I found this strange, that after it failed at runtime, I was indeed able to find the missing case. However, I’d have expected the compiler to at least issue a warning if not an error. Alas, it issued neither. The SO post recommended adding the -deprecated flag. I just wanted to see what would happen, to see if the SO advise is good advise or not.

I’m afraid you’re hitting the limits of the compiler here. It does its best to provide exhaustiveness checks, but it can only go so far there. I’d bet that it’s just plain impossible in the general case – when you add guards into the mix, I suspect it becomes a variant of the halting problem – and more practically, it can only do so much without slowing the compiler down unreasonably.

In practice, I only expect the compiler to provide good exhaustiveness checking when I am matching on (potentially nested) case classes without guards…