*
 * <ul>
 *   <li>Kotlin, for which it makes the type-variable usage (a) a Kotlin platform type when the type
 *       argument is non-nullable and (b) nullable when the type argument is nullable. We use this
 *       to "undo" {@link ElementTypesAreNonnullByDefault}. It is the best we can do for Kotlin
 *       under our current constraints.
 *   <li>NullAway, which will <a

 *
 * <ul>
 *   <li>Kotlin, for which it makes the type-variable usage (a) a Kotlin platform type when the type
 *       argument is non-nullable and (b) nullable when the type argument is nullable. We use this
 *       to "undo" {@link ElementTypesAreNonnullByDefault}. It is the best we can do for Kotlin
 *       under our current constraints.
 *   <li>NullAway, which will <a

 *
 * <ul>
 *   <li>Kotlin, for which it makes the type-variable usage (a) a Kotlin platform type when the type
 *       argument is non-nullable and (b) nullable when the type argument is nullable. We use this
 *       to "undo" {@link ElementTypesAreNonnullByDefault}. It is the best we can do for Kotlin
 *       under our current constraints.
 *   <li>NullAway, which will <a

 *
 * <ul>
 *   <li>Kotlin, for which it makes the type-variable usage (a) a Kotlin platform type when the type
 *       argument is non-nullable and (b) nullable when the type argument is nullable. We use this
 *       to "undo" {@link ElementTypesAreNonnullByDefault}. It is the best we can do for Kotlin
 *       under our current constraints.
 *   <li>NullAway, which will <a

 *
 * <ul>
 *   <li>Kotlin, for which it makes the type-variable usage (a) a Kotlin platform type when the type
 *       argument is non-nullable and (b) nullable when the type argument is nullable. We use this
 *       to "undo" {@link ElementTypesAreNonnullByDefault}. It is the best we can do for Kotlin
 *       under our current constraints.
 *   <li>NullAway, which will <a

 *
 * <ul>
 *   <li>Kotlin, for which it makes the type-variable usage (a) a Kotlin platform type when the type
 *       argument is non-nullable and (b) nullable when the type argument is nullable. We use this
 *       to "undo" {@link ElementTypesAreNonnullByDefault}. It is the best we can do for Kotlin
 *       under our current constraints.
 *   <li>NullAway, which will <a

 *
 * <ul>
 *   <li>Kotlin, for which it makes the type-variable usage (a) a Kotlin platform type when the type
 *       argument is non-nullable and (b) nullable when the type argument is nullable. We use this
 *       to "undo" {@link ElementTypesAreNonnullByDefault}. It is the best we can do for Kotlin
 *       under our current constraints.
 *   <li>NullAway, which will <a

 *
 * <ul>
 *   <li>Kotlin, for which it makes the type-variable usage (a) a Kotlin platform type when the type
 *       argument is non-nullable and (b) nullable when the type argument is nullable. We use this
 *       to "undo" {@link ElementTypesAreNonnullByDefault}. It is the best we can do for Kotlin
 *       under our current constraints.
 *   <li>NullAway, which will <a

### Import `HTTPException`

```Python hl_lines="1"
{!../../docs_src/handling_errors/tutorial001.py!}
```

### Lance o `HTTPException` no seu código.

`HTTPException`, ao fundo, nada mais é do que a conjunção entre uma exceção comum do Python e informações adicionais relevantes para APIs.

E porque é uma exceção do Python, você não **retorna** (return) o `HTTPException`, você lança o (raise) no seu código.

    /*
     * TODO(cpovirk): `return (V) removedValue` once our checker permits that.
     *
     * (We promoted a class of warnings into errors because sometimes they indicate real problems.
     * But now we need to "undo" some instance of spurious errors, as discussed in
     * https://github.com/jspecify/checker-framework/issues/8.)
     */
    return removedValue == null ? null : (V) removedValue;
  }

  @Override