Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detailed Exception Handling inside different filip methods #305

Open
RCX112 opened this issue Jul 15, 2024 · 1 comment · May be fixed by #335
Open

Detailed Exception Handling inside different filip methods #305

RCX112 opened this issue Jul 15, 2024 · 1 comment · May be fixed by #335
Assignees
Labels
feature request Request a potential feature

Comments

@RCX112
Copy link
Collaborator

RCX112 commented Jul 15, 2024

Is your feature request related to a problem? Please describe.

Currently there is the problem that several filip methods do not throw detailed exceptions. For example, if I use the post_device or update_device method of the IoT Agent, only a simple request error with a HTTP status code is thrown in the event of an exception, without any further details:

iota_client.post_device(device=device1)

try:
    iota_client.post_device(device=device1)  # Exception because duplicate device
except Exception as e:
    print(e)

The output of the exception is only 409 Client Error: Conflict for url: http://localhost:4041/iot/devices with no more detailed information. Currently you have to use the debugger to find out that the exception is thrown by a duplicate Device in this case.

The same 409 error is thrown when I want to update a Device in the IoT-Agent (note that I used newer versions of the OCB and the IoT Agent):

iota_client.post_device(device=device1)

try:
    iota_client.update_device(device=device1)  # Exception because no device entity in OCB
except Exception as e:
    print(e)

Describe the solution you'd like

The filip functions currently raise only the status code, but it would be very useful to also raise the content of the request responses. We could maybe create a custom exception, which contains more detailed informations about the errors. The update_device method could look for example like this:

class DeviceUpdateException(Exception):
    def __init__(self, message, response):
        super().__init__(message)
        self.response = response

class IoTAClient(BaseHttpClient):
    def update_device(self, *, device: Device, add: bool = True) -> None:
        """
        Updates a device from the device registry.
        Adds, removes attributes from the device entry and changes
        attributes values.
        It does not change device settings (endpoint,..) and only adds
        attributes to the corresponding entity, their it does not
        change any attribute value and does not delete removed attributes

        Args:
            device:
            add (bool): If device not found add it
        Returns:
            None
        """
        url = urljoin(self.base_url, f'iot/devices/{device.device_id}')
        headers = self.headers
        try:
            res = self.put(url=url, headers=headers, json=device.model_dump(
                include={'attributes', 'lazy', 'commands', 'static_attributes'},
                exclude_none=True))
            if res.ok:
                self.logger.info("Device '%s' successfully updated!",
                                 device.device_id)
            elif (res.status_code == 404) & (add is True):
                self.post_device(device=device, update=False)
            else:
                res.raise_for_status()
        except requests.RequestException as err:
            msg = f"Could not update device '{device.device_id}'"
            self.log_error(err=err, msg=msg)
            raise DeviceUpdateException(msg, res) from err

Here DeviceUpdateException was added as a custom exception, which contains the request response as an attribute. We have indeed some use cases where the detailed exception handling would be very useful.

Additional context

  • Orion Version: 3.11.0
  • IoT Agent (json) Version: 3.3.0
@RCX112 RCX112 added the feature request Request a potential feature label Jul 15, 2024
@RCX112 RCX112 self-assigned this Aug 6, 2024
Copy link

github-actions bot commented Aug 6, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Request a potential feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant