|
| 1 | +# Exceptions |
| 2 | + |
| 3 | +Exceptions are a necessary aspect of any software product (Go notwithstanding), |
| 4 | +and care must be taken in how they're exposed. This document describes how |
| 5 | +smithy-python clients will expose exceptions to customers. |
| 6 | + |
| 7 | +## Goals |
| 8 | + |
| 9 | +* Every exception raised by a Smithy client should be catchable with a single, |
| 10 | + specific catch statement (that is, not just `except Exception`). |
| 11 | +* Every modeled exception raised by a service should be catchable with a single, |
| 12 | + specific catch statement. |
| 13 | +* Exceptions should contain information about retryablility where relevant. |
| 14 | + |
| 15 | +## Specification |
| 16 | + |
| 17 | +Every exception raised by a Smithy client MUST inherit from `SmithyException`. |
| 18 | + |
| 19 | +```python |
| 20 | +class SmithyException(Exception): |
| 21 | + """Base exception type for all exceptions raised by smithy-python.""" |
| 22 | +``` |
| 23 | + |
| 24 | +If an exception that is not a `SmithyException` is thrown while executing a |
| 25 | +request, that exception MUST be wrapped in a `SmithyException` and the |
| 26 | +`__cause__` MUST be set to the original exception. |
| 27 | + |
| 28 | +Just as in normal Python programming, different exception types SHOULD be made |
| 29 | +for different kinds of exceptions. `SerializationException`, for example, will |
| 30 | +serve as the exception type for any exceptions that occur while serializing a |
| 31 | +request. |
| 32 | + |
| 33 | +### Retryability |
| 34 | + |
| 35 | +Not all exceptions need to include information about retryability, as most will |
| 36 | +not be retryable at all. To avoid overly complicating the class hierarchy, |
| 37 | +retryability properties will be standardized as a `Protocol` that exceptions MAY |
| 38 | +implement. |
| 39 | + |
| 40 | +```python |
| 41 | +@dataclass(kw_only=True) |
| 42 | +@runtime_checkable |
| 43 | +class RetryInfo(Protocol): |
| 44 | + is_retry_safe: bool | None = None |
| 45 | + """Whether the exception is safe to retry. |
| 46 | +
|
| 47 | + A value of True does not mean a retry will occur, but rather that a retry is allowed |
| 48 | + to occur. |
| 49 | +
|
| 50 | + A value of None indicates that there is not enough information available to |
| 51 | + determine if a retry is safe. |
| 52 | + """ |
| 53 | + |
| 54 | + retry_after: float | None = None |
| 55 | + """The amount of time that should pass before a retry. |
| 56 | +
|
| 57 | + Retry strategies MAY choose to wait longer. |
| 58 | + """ |
| 59 | + |
| 60 | + is_throttle: bool = False |
| 61 | + """Whether the error is a throttling error.""" |
| 62 | +``` |
| 63 | + |
| 64 | +If an exception with `RetryInfo` is received while attempting to send a |
| 65 | +serialized request to the server, the contained information will be used to |
| 66 | +inform the next retry. |
| 67 | + |
| 68 | +### Service Exceptions |
| 69 | + |
| 70 | +Exceptions returned by the service MUST be a `CallException`. `CallException`s |
| 71 | +include a `fault` property that indicates whether the client or server is |
| 72 | +responsible for the exception. HTTP protocols can determine this based on the |
| 73 | +status code. |
| 74 | + |
| 75 | +Similarly, protocols can and should determine retry information. HTTP protocols |
| 76 | +can generally be confident that a status code 429 is a throttling error and can |
| 77 | +also make use of the `Retry-After` header. Specific protocols may also include |
| 78 | +more information in protocol-specific headers. |
| 79 | + |
| 80 | +```python |
| 81 | +type Fault = Literal["client", "server"] | None |
| 82 | +"""Whether the client or server is at fault. |
| 83 | +
|
| 84 | +If None, then there was not enough information to determine fault. |
| 85 | +""" |
| 86 | + |
| 87 | + |
| 88 | +@dataclass(kw_only=True) |
| 89 | +class CallException(SmithyException, RetryInfo): |
| 90 | + fault: Fault = None |
| 91 | + message: str = field(default="", kw_only=False) |
| 92 | +``` |
| 93 | + |
| 94 | +#### Modeled Exceptions |
| 95 | + |
| 96 | +Most exceptions thrown by a service will be present in the Smithy model for the |
| 97 | +service. These exceptions will all be generated into the client package. Each |
| 98 | +modeled exception will be inherit from a generated exception named |
| 99 | +`ServiceException` which itself inherits from the static `ModeledException`. |
| 100 | + |
| 101 | +```python |
| 102 | +@dataclass(kw_only=True) |
| 103 | +class ModeledException(CallException): |
| 104 | + """Base exception to be used for modeled errors.""" |
| 105 | +``` |
| 106 | + |
| 107 | +The Smithy model itself can contain fault information in the |
| 108 | +[error trait](https://smithy.io/2.0/spec/type-refinement-traits.html#smithy-api-error-trait) |
| 109 | +and retry information in the |
| 110 | +[retryable trait](https://smithy.io/2.0/spec/behavior-traits.html#retryable-trait). |
| 111 | +This information will be statically generated onto the exception. |
| 112 | + |
| 113 | +```python |
| 114 | +@dataclass(kw_only=True) |
| 115 | +class ServiceException(ModeledException): |
| 116 | + pass |
| 117 | + |
| 118 | + |
| 119 | +@dataclass(kw_only=True) |
| 120 | +class ThrottlingException(ServcieException): |
| 121 | + fault: Fault = "client" |
| 122 | + is_retry_safe: bool | None = True |
| 123 | + is_throttle: bool = True |
| 124 | +``` |
0 commit comments