fix: Give better error message on non-existent device

[DominicOram]

Fixes #1193

[codecov]

Codecov Report

❌ Patch coverage is 75.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 94.86%. Comparing base (6c52f00) to head (50c5192).

Files with missing lines	Patch %	Lines
src/blueapi/core/context.py	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1194      +/-   ##
==========================================
- Coverage   95.03%   94.86%   -0.18%     
==========================================
  Files          43       43              
  Lines        2782     2784       +2     
==========================================
- Hits         2644     2641       -3     
- Misses        138      143       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tpoliaw]

Having a different message for the device not existing and the device being the wrong type makes a lot of sense but I'm not sure about listing the available devices in the error. The list will include a whole load of devices that are also not valid while not including some that are, eg it would only list stage and not stage.x and stage.y (unless this has changed recently, there was some discussion about it a while back).

Possibly out of scope of this PR but would it also make sense to change the message for the invalid type case to include the type it actually is? At the moment it is only <name> is not of type <type>.

[DominicOram]

I'm not sure about listing the available devices in the error

Fair enough but I do think that given this is the external API it's close to user facing so would like to be as helpful as possible. How about we list all known devices with the correct type and give the caveat that the list may not be exhaustive?

Possibly out of scope of this PR but would it also make sense to change the message for the invalid type case to include the type it actually is?

Yh, happy to do this

[tpoliaw]

How about we list all known devices with the correct type and give the caveat that the list may not be exhaustive?

Sure, that works. I think #1129 was the change for including all devices and would get rid of the caveat.

[callumforrester]

Since devices are a tree and blueapi supports resolving them recursively (foo.bar.baz etc.), devices.keys() is not the complete set of available devices. So you might just get [sample_stage] instead of [sample_stage.x, sample_stage.y], for example. Not sure if it really matters here but worth knowing.

Relates to #1129

[callumforrester]

Nevermind, @tpoliaw beat me to it

[tpoliaw]

It would be good to get this in. @DominicOram are you ok with me updating this? I think just differentiating between missing and wrong type for now, then we can list devices if/when #1129 gets resolved.

[DominicOram]

It would be good to get this in. @DominicOram are you ok with me updating this?

I was, thank you for doing it.