Skip to content

allow users to throw an explicit exception to allow sending error response message through INTERSECT #24

@Lance-Drane

Description

@Lance-Drane

When handling errors for request/command messages, the current approach we have with error handling is this:

  • pydantic.ValidationError exceptions are captured by the INTERSECT-SDK, and their associated error messages are sent through INTERSECT (with the has_error=True flag)
  • do not catch BaseException exceptions, because these are generally not intended to be caught
  • all other exceptions, whether deliberately thrown or uncaught, are caught by the INTERSECT-SDK and then logged on the server, but the response message will simply say something generic like "Server messed up". This is important because some exceptions could leak sensitive information.

We want to keep all of this behavior, but want to add an additional functionality:

  • if the Service throws a specific IntersectUserException, send the error message in the response message. This allows for clients to be informed of what went wrong, without having to rely on all bubbled-up exceptions going through Pydantic; for example, if a user is trying to get data from a service-managed database and submits a database ID with the correct format, but the database does not have an entry with this ID, an IntersectUserException should realistically be raised at this point.

IntersectUserException itself should always have a consistent structure. Note that it should only be raised if the submitted data was somehow incorrect; if the server messed up, IntersectUserException should not be raised.

For the current implementation of IntersectUserException

  • just require some sort of descriptive string message passed through

For future implementations of IntersectUserException

  • it may make sense to require other fields on the Exception (i.e. a numerical code)
  • more advanced implementations could even have an error schema per endpoint, and allow for users to build these out with custom properties. This may be important in the far future where we want exception parameters to be machine-readable and potentially parsed by an LLM.

Metadata

Metadata

Assignees

No one assigned

    Labels

    ready_for_releaseIssue has been completed, but the resolution has not been pushed out to a release.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions