fn-unparsed-text-036 throws wrong error

[Chris Hillery]

fn-unparsed-text-036 throws FOUT1170, where FOTS claims that it should throw FOUT1190.

This wouldn't normally be too big a deal (FOTS does not require 100% matching error codes), but this test is slightly odd because it DOES throw the right error when the FOTS driver enables plan serialization. It was the only test in FOTS that changed behaviour when plan serialization testing was enabled. That smells a little funky and is worth investigating, although as a relatively low priority.

[Juan Zacarias (juan457)]

I am not sure why this happened, But I noticed this problem in my unparsed-text branch, It seems it seems the error was being run but catched by another part of the code therefore ignores, I am not actually when or where this error happens since I tried to debug it with no look. Even though I fixed the error throw by checking for this error before asking for the resource that holds the text and this solved the problem.

I will link this bug to my other branch with holds the fix.

[Chris Hillery (ceejatec)]

If you are wondering how this passed the RQ before, it's because FOTS tests don't actually fail if they throw the wrong error. FOTS does not require exactly one correct error for negative tests, because at least in a number of cases it's impossible to say exactly what the "right error" is. That's why this is only a medium-priority problem.