Do not fail hard if an ORT result contains no analyzer result

[sschuberth]

Pragmatically, when being asked to operate on empty input, then doing
nothing is the right thing to do, esp. in library code where the caller
should implement custom error handling.

However, as it is rather unusual to not even have an analyzer result in a
ORT result, still emit a warning in that case.

Signed-off-by: Sebastian Schuberth sebastian.schuberth@bosch.io

[oheger-bosch]

Such empty input files are indeed a strange corner case. Logging a warning in this case makes certainly sense.

I was just thinking whether a tool running on such input should actually do nothing or whether it should at least produce an empty result of its own type. Then it would be possible to distinguish whether specific tools have been run on a concrete ORT result or not.

[sschuberth]

or whether it should at least produce an empty result of its own type.

Given that we agree that ORT result files without an analyzer result are a corner cases, I'm not actually feeling comfortable with deliberately creating more such corner cases...

[oheger-bosch]

How could an ORT result without an analyzer section be created in practice? Is this just a theoretical case? If so, I would even say it is reasonable to ignore the case at all. (And if anybody does strange things, they will get what they deserve.)

Or, as an alternative approach: Would it be possible to make the analyzer field in the ORT result mandatory?

[sschuberth]

How could an ORT result without an analyzer section be created in practice?

Currently, no ORT cli tool would write out an ORT result file without an analyzer result. I'm not sure about the helper-cli tools, though, e.g. when fed with "odd" options, or your new JSLT tool.

Would it be possible to make the analyzer field in the ORT result mandatory?

That's worth a thought. Although I currently like the fact that data-model-wise all results are nullable, and are treated the same.

[neubs-bsi]

Could it be worth mentioning in the warning that this will lead to no vulnerability information being retrieved/ an unchanged OrtResult?

[sschuberth]

Done.

[mnonnenmacher]

Pragmatically, when being asked to operate on empty input, then doing
nothing is the right thing to do, esp. in library code where the caller
should implement custom error handling.

I don't understand that sentence, if with this change there is no exception anymore, how is the caller supposed to implement custom error handling?
If this code is used as a library, and for example the caller passed an ORT result with only scan results because they expect it to work, wouldn't it be easier for the user to find the issue if an exception is thrown, instead of having to notice the warning in the logs?

[sschuberth]

I don't understand that sentence, if with this change there is no exception anymore, how is the caller supposed to implement custom error handling?

I was meaning to say that, if the caller does want to handle empty files differently, it should check whether the file it empty before calling the function.

If this code is used as a library, and for example the caller passed an ORT result with only scan results because they expect it to work, wouldn't it be easier for the user to find the issue if an exception is thrown, instead of having to notice the warning in the logs?

Probably yes, but the caller would still need to (programmatically) inspect the exception message to find out whether it was thrown due to a missing analyzer result or something else. Also no nice.

@mnonnenmacher, what do you think about @oheger-bosch's suggestion to instead make the analyzer result non-nullable?