For test data, better error message when the "Library" or "Datasets" tab, or the column headers within them are not found or malformed

[chowsanthony]

Reproduce step: Name the test data spreadsheet tab "datasets" instead of "Datasets."

When the "Datasets" tab is not found or malformed, I see this error message, which I found a tad cryptic and not easy to troubleshoot:

{
  "error": "KeyError",
  "message": "\"one or more datasets missing the following keys {'label'}\""
}

In contrast. when the "Library" tab is not found or malformed, I see this error message, which I found more informative:

{
  "MI": [
    {
      "executionStatus": "execution_error",
      "domain": "MI",
      "variables": [],
      "message": "rule execution error",
      "errors": [
        {
          "error": "An unknown exception has occurred",
          "message": "Missing standard and version data"
        }
      ]
    }
  ]
}

Lastly, I hope the error message to include some coping mechanism, e.g.,, "Make sure there is a 'Datasets' tab, case-sensitive."

Another example: Product and Version within Library tab are also case sensitive and don't provide appropriate error messages.

[gerrycampion]

Another example: Product and Version within Library tab are also case sensitive and don't provide appropriate error messages.

[SFJohnson24]

i know this ticket is from rule editor--we are decommissioning it but I do think there should be a more user-friendly error for the metadata readers and data reader classes

[SFJohnson24]

I discussed with Rakesh this morning the A/C:
Some catches have been made for the excel reader already.
I also would like to see:

a. catches wrapped around the various reader classes in case an error occurs which returns an error that is user friendly.  This may need to be the metadata readers if they get called first in the validation script. This may have already been handled partially with the encoding ticket but I think it would be good to have a catch surrounding our readers in-case the data is malformed that tells users 'your data file is incorrect/corrupted/etc and cant be read'

b. given the decommisioning of editor, i think we should add logic for the standard at the start of core.py. we have the custom-standard flag which should override this. We should have a list of constant standards supported from its file in the enum folder. It should check if the standard.lower() is a supported standard

cdisc-rules-engine/core.py

Line 461 in 380f580

standard = standard.lower()

c. There is still a possibility they give an incorrect standard/version combo--i imagine this will hit the library service and cause an error. We should wrap the service lookup in an error catch if it fails to find library metadata for the standard and version provided. This will also be the error that editor will have if the library tab has incorrect standard/version in the library tab. get_library_metadata_from_cache() this may be in this function call

d. catch for malformed CT package lookup in library service -- (I imagine this would be at the same location as c when the cache lookup is occurring).

aside:

cdisc-rules-engine/scripts/run_validation.py

Line 232 in 380f580

def run_single_rule_validation(

if we add a small catch/error here-- this will catch bad library lookup spefically 240-263, this will account for incorrect ct/standard/versions coming from editor.