[REQ] [Python] Add custom exceptions for HTTP status codes 409 (Conflict) and 422 (Unprocessable Entity)

[mbezhanov]

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

This issue expands on #2151.

Currently, the Python generator provides custom exception classes for the following HTTP error codes:

• 400 (Bad Request)
• 401 (Unauthorized)
• 403 (Forbidden)
• 404 (Not Found)

However, other common HTTP status codes like 409 (Conflict) and 422 (Unprocessable Entity) are not handled by custom exception classes:

• 409 is often used to indicate a conflict in the request, such as trying to create a resource that already exists.
• 422 is commonly used in frameworks like FastAPI to signal validation errors in the request payload.

The lack of dedicated exception classes for these codes makes error handling less intuitive, because developers need to catch a generic ApiException in order to inspect and classify the error.

Describe the solution you'd like

Add custom exception classes for HTTP status codes 409 and 422, similar to the existing custom exceptions for other 4XX codes. More specifically, something like:

if http_resp.status == 409:
    raise ConflictException(http_resp=http_resp, body=body, data=data)

if http_resp.status == 422:
    raise UnprocessableEntityException(http_resp=http_resp, body=body, data=data)

This modification would align with the current implementation while providing more convenient and meaningful error handling for these particular HTTP status codes.

Describe alternatives you've considered

The current alternative is going with something like:

try:
  # API call expected to produce a 409 or 422 goes here.
except ApiException as e:
  if e.status == 409:
    # Code expected to handle the 409 error goes here.
  elif e.status == 422:
    # Code expected to handle the 422 error goes here.
  else:
    raise

Although this code is valid, it's not as elegant as using dedicated exception classes. The need to manually inspect the status field to handle specific cases adds unnecessary boilerplate and detracts from the clarity of the error-handling logic.

Additional context

I'm ready to submit a PR with these changes for consideration.

[OM-HASE]

@mbezhanov, giving the final solution with PR.

[mbezhanov]

@OM-HASE I'm not sure your PR is complete. Please have a look at #7321 for how the previous change was implemented. It included changes to the petstore-api examples.

[OM-HASE]

@mbezhanov, changes will be made shortly, thanks for telling it.