Only make additional Python checks if no schema errors

[GraemeWatt]

I've noticed a few recent error emails from the submission system with An unexpected error occurred: float() argument must be a string or a number, not 'NoneType' and an exception raised in Sentry (example) with Final attempt of process_saved_file for recid 1636571704 failed. Resetting to previous status. This happens because null values are given for some fields, e.g.

dependent_variables:
- header: {name: '$d^{2}\sigma/d\it{p}_{T}d\eta(mb \it{c}/GeV)$'}
  qualifiers:
  - {name: '$\it{p}_{T,jet}^{ch} (GeV/c)$', value: 'Jetptg R=0.2'}
  values:
  - value: 
    errors:
    - {symerror: , label: '$p_{T}$ statistical'}
    - {symerror: , label: '$p_{T}$ systematic'}
  - value: 
    errors:
    - {symerror: , label: '$p_{T}$ statistical'}
    - {symerror: , label: '$p_{T}$ systematic'}

Here, the value and symerror will show as None in Python, giving an uncaught exception TypeError: float() argument must be a string or a number, not 'NoneType' from error = float(error). Probably it would be easier just to make the additional Python checks such as check_for_zero_uncertainty if there are no validation errors from the JSON schema (i.e. revert a change made in dd5d463). Otherwise, the Python code making the additional checks cannot make any assumptions about the validity of the fields.

Could you please address this issue, @alisonrclarke, together with #39?

[alisonrclarke]

Instead of only doing the additional check is there are no schema errors, would it be OK to do them but wrap in try/except, ignoring any exceptions if there are already errors?

I just think it's helpful to the end user to show as many errors as possible first time.

[GraemeWatt]

Yes, that's a better idea than missing out the additional checks completely.