Fix crash from loading into Muon Analysis interface

[GuiMacielPereira]

This simple change forces the ADS to check whether the workspace name i.e. load_result["DeadTimeTable"] actually exists. If it doesn't, it gives an error which is caught by the widget, instead of closing the widget and crashing mantid.

Not an ideal solution, but a quick and simple one.

Description of work

Previously a crash happened after trying to load data into the Muon Analysis interface whenever a file did not produce the "DeadTimeTable` workspace, which the interface assumes is always the case. The nexus file in question is an old one (from 2010), and I suspect that maybe at the time they did not or could not record this type of data.

Regardless, this file is loaded by LoadMuonNexus v1 and I confirmed that indeed some files might not produce the DeadTimeTable output and this is not a bug.

So the issue is that Muon Analysis assumes all workspaces will output this table when in fact this might not be the case, which was crashing the interface.

The best solution would be to still open the interface and disable only the functunality that uses DeadTimeTable. This way useers would still have most of the functunality available. I checked and this would be quite simple, I think disabling an option in the combobox in one of the tabs would do it. However, this would still require messing around with the observers and connections between different tabs, and is not as self-contained as I would have hoped. So for the sake of the release, I think its better if we put in this quick fix now, and I can work out a better solution afterwards if necessary.

Summary of work

As per issue #38210, the error is now caught by the widget and mantid no longer crashes.

Fixes #38210

To test:

Follow the instructions on the original issue, you should see an error window but the interface should remain open.

---

Reviewer

Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.

Code Review

• Is the code of an acceptable quality?
• Does the code conform to the coding standards?
• Are the unit tests small and test the class in isolation?
• If there is GUI work does it follow the GUI standards?
• If there are changes in the release notes then do they describe the changes appropriately?
• Do the release notes conform to the release notes guide?

Functional Tests

• Do changes function as described? Add comments below that describe the tests performed?
• Do the changes handle unexpected situations, e.g. bad input?
• Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

Gatekeeper

If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.

[MohamedAlmaki]

Tested on my machine and it works as expected, thanks for the fix