There are several places in the tool execution algorithms where we either collapse distinct failures into UnknownError, or have an inline issue noting that a more specific error should eventually be plumbed back to the caller via promise rejection.
For example:
- A requested tool no longer exists --> the spec suggests
NotFoundError
- Tool input cannot be parsed as JSON → the spec suggests
DataError
executeTool() currently uses UnknownError for several distinct failures involving the target document, origin, tool registration, and tool exposure. Maybe some of these are fine but we should be more explicit where we can.
We should audit these failure cases, decide on the right exception for each, and update the spec accordingly so that the right exception reaches the caller.
Note that this issue is about platform-level execution failures. Tool-produced, or application-level failures (i.e., the execute() callback runs but the tool wants to report that it could not or would not perform the requested operation) are a separate question tracked in #282.
There are several places in the tool execution algorithms where we either collapse distinct failures into
UnknownError, or have an inline issue noting that a more specific error should eventually be plumbed back to the caller via promise rejection.For example:
NotFoundErrorDataErrorexecuteTool()currently usesUnknownErrorfor several distinct failures involving the target document, origin, tool registration, and tool exposure. Maybe some of these are fine but we should be more explicit where we can.We should audit these failure cases, decide on the right exception for each, and update the spec accordingly so that the right exception reaches the caller.
Note that this issue is about platform-level execution failures. Tool-produced, or application-level failures (i.e., the
execute()callback runs but the tool wants to report that it could not or would not perform the requested operation) are a separate question tracked in #282.