Fix: update internal position after ASI filter and slider filter wheel move

[juhelh]

Changes

• Updates internal position attributes (self.filter_wheel_position, self.dichroic_position) after successful hardware move.

• Wraps hardware move calls in try/except with logging and exception re-raise.

Motivation

Catches a failed move early. Makes sure internal position always follows the actual position.

[AdvancedImagingUTSW]

For the most part, we have refrained from raising fatal exceptions which will crash the entire program. Non-experts also fail to check the logs, so some sort of more obvious warning is often necessary.

One approach we have taken is to pass a warning back to the controller, which then present a dialog box to the user. For example, if you look in model.py, ...

self.event_queue.put(
   (
      "warning",
      "An error happened. Please read the log files for details!",
      )
)

@annie-xd-wang - Is there a way to pass a command from the device layer to the event queue in the model?

[annie-xd-wang]

We can update the signal thread a little bit to pass exceptions as warnings to the user.

[AdvancedImagingUTSW]

@annie-xd-wang - I think that is an excellent idea. Perhaps not all exceptions, but a special class of exceptions. We could initialize these at the base layer for each device class, or even possibly every base class could inherit an exception type which bubbles up to the model and then directly informs the user of the problem.

[AdvancedImagingUTSW]

Merging with the expectation that we will implement a custom exception class to communicate configuration-based errors with the user via the event queue in the model and the tkinter message box.

[annie-xd-wang]

A custom exception class sounds like a great and practical idea. It would give us a clear way to bubble up only the relevant errors to the user without exposing low-level details.

[juhelh]

Ah, I see why you'd like to avoid fatal exceptions now. A dialog box sounds like it could be useful for non-experts (I see you already implemented something like that - nice!). Don't know if you kept the logging as well, but that would be my suggestion - I think it's really useful when people run into problems to be able to trace exactly what the chain of events was.

Glad to see the PR sparked some discussion!

[AdvancedImagingUTSW]

@annie-xd-wang is awesome, and implemented it immediately in #1120, which I just merged. If you feel like testing it out, you would have to raise a UserVisibleException, which can be imported from the utils module. Any text that you provide in the warning should show up as a popup.