Essa exceção será manipulada, contudo, pelo `unicorn_exception_handler`.

Dessa forma você receberá um erro "limpo", com o HTTP status code `418` e um JSON com o conteúdo:

```JSON
{"message": "Oops! yolo did something. There goes a rainbow..."}
```

/// note | Detalhes Técnicos

Nesse caso você tem:

* `ItemsService`
* `UsersService`

### Nomes dos métodos do cliente { #client-method-names }

Agora os nomes dos métodos gerados como `createItemItemsPost` não parecem muito “limpos”:

```TypeScript
ItemsService.createItemItemsPost({name: "Plumbus", price: 5})
```

...isso ocorre porque o gerador de clientes usa o **ID de operação** interno do OpenAPI para cada *operação de rota*.

Aquí, si solicitas `/unicorns/yolo`, la *path operation* lanzará un `UnicornException`.

Pero será manejado por el `unicorn_exception_handler`.

Así que recibirás un error limpio, con un código de estado HTTP de `418` y un contenido JSON de:

```JSON
{"message": "Oops! yolo did something. There goes a rainbow..."}
```

/// note | Nota Técnica

Adicionalmente, una tarea en segundo plano normalmente es un conjunto independiente de lógica que debería manejarse por separado, con sus propios recursos (por ejemplo, su propia conexión a la base de datos).

Así, probablemente tendrás un código más limpio.

///

* Valida **estruturas complexas**:
    * Use modelos hierárquicos do Pydantic, `List` e `Dict` do `typing` do Python, etc.
    * Validadores permitem que esquemas de dados complexos sejam limpos e facilmente definidos, conferidos e documentados como JSON Schema.
    * Você pode ter **JSONs aninhados** profundamente e tê-los todos validados e anotados.
* **Extensível**:

Mas nesse caso, se você trouxesse os 8 ex-caixas / cozinheiros / agora-faxineiros, e cada um deles (mais você) pudessem dividir a casa para limpá-la, vocês fariam toda a limpeza em **paralelo**, com a ajuda extra, e terminariam muito mais cedo.

Nesse cenário, cada um dos faxineiros (incluindo você) poderia ser um processador, fazendo a sua parte do trabalho.