Add additional error handling for livery parsing.

[SnappyComebacks]

Several users of DCS_Liberation had exceptions raised at the call countries_table.values(). (See dcs-liberation/dcs_liberation#3231 for context). It is my understanding that this is caused by an installed custom livery that has not been configured by the livery developer correctly.

I have added a try/except statements to try to more gracefully handle the error that users have been encountering. In addition, I wrapped the from_file code with a try/except to skip a failing livery, log the error, and move on.

I do not have any custom liveries downloaded, and users have not provided the failing liveries, so I was unable to test the failure.

[DanAlbert]

This causes the wrong data to be exposed. A Livery with None countries is available to all countries. We don't know what countries it's valid for. The correct thing to do would be to skip this livery.

[SnappyComebacks]

I can change this if you want, but I had left it with the same behavior as previous. I am surprised to see this change requested, as my interpretation of the prior behavior was it is desirable to allow for an easy way to let a livery be available to all countries.

[DanAlbert]

The prior behavior is that if the livery does not set the countries field, it is available for all countries. That is DCS's behavior, we have no say in it.

With your change applied, liveries with liveries fields that we failed to parse will be available to all countries in pydcs (because of the except branch does not return None). They probably are not available to all countries in DCS, because if that's what the author wanted, they wouldn't have set it at all.

[DanAlbert]

I'm betting I wasn't clear enough on which part I think the problem is. countries = None isn't actually the problem here, it's just the beginning of the changed block that has the problem, and the problem is a missing line, which I of course can't comment on :) Adding return None after logging.exception() would work fine.

[DanAlbert]

If my explanation doesn't match your understanding, lmk which part is wrong. It seems like you and I are 100% agreed on the goal here, one of us has just misunderstood some part of the behavior either before or after.

[DanAlbert]

Based on your comments, I may have misread the PR. I'll take another look tomorrow.

[Raffson]

According to Starfire's bug-report, I guess the livery that's causing the issue is doing something like this:
countries = "USA"

To be honest, I don't remember how DCS will interpret this but it can go two ways:

1. DCS will cope with this just fine and the livery becomes available to the specified country
2. DCS ignores the value and interprets it as valid for all countries

This is obviously assuming that nothing changed in DCS since I wrote the original code.

Also, may I suggest ditching the idea to deserialize the entire livery's description file? The regex approach worked fine, and if the second case is DCS' actual behavior, then that code should work out-of-the-box. Granted, the rest of the refactor was indeed necessary and well executed, but switching up the approach to extract the required data seems to be the root cause of the problem.

[Raffson]

Just verified, the second case applies. I can almost with certainty say that the error is indeed caused by assigning a string to countries in the description.lua file, and having had a better look at the PR I'm pretty sure this will not only provide you with extra logging, but actually solve the issue because countries is indeed supposed to stay None if "bogus stuff" is assigned to countries because DCS will indeed interpret it as valid for all countries.

[Starfire13]

Some other examples of non-standard "countries" lines in liveries, courtesy of JabbyJabara.