```Python hl_lines="1  5-7" title="app/dependencies.py"
{!> ../../docs_src/bigger_applications/app_an/dependencies.py!}
```

////

//// tab | Python 3.8+ non-Annotated

/// tip

Prefer to use the `Annotated` version if possible.

///

```Python hl_lines="1  4-6" title="app/dependencies.py"
{!> ../../docs_src/bigger_applications/app/dependencies.py!}
```

////

/// tip

    }
    return Collections.unmodifiableList(causes);
  }

  /**
   * Returns {@code throwable}'s cause, cast to {@code expectedCauseType}.
   *
   * <p>Prefer this method instead of manually casting an exception's cause. For example, {@code
   * (IOException) e.getCause()} throws a {@link ClassCastException} that discards the original

  /**
   * The HTTP <a
   * href="https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-color-scheme">{@code
   * Sec-CH-Prefers-Color-Scheme}</a> header field name.
   *
   * <p>This header is experimental.
   *
   * @since 31.0
   */
  public static final String SEC_CH_PREFERS_COLOR_SCHEME = "Sec-CH-Prefers-Color-Scheme";

  /**
   * The HTTP <a

 *
 * <p><b>Important note:</b> Unlike {@code InetAddress.getByName()}, the methods of this class never
 * cause DNS services to be accessed. For this reason, you should prefer these methods as much as
 * possible over their JDK equivalents whenever you are expecting to handle only IP address string
 * literals -- there is no blocking DNS penalty for a malformed string.
 *

 * the {@code E} type variable declared by class {@code List} naturally maps to {@code String} in
 * the context of {@code class MyStringList implements List<String>}). In such case, prefer to use
 * {@link TypeToken#resolveType} since it's simpler and more type safe. This class should only be
 * used when the type mapping isn't implied by the static type hierarchy, but provided through other

The `string()` method on response body is convenient and efficient for small documents. But if the response body is large (greater than 1 MiB), avoid `string()` because it will load the entire document into memory. In that case, prefer to process the body as a stream.

=== ":material-language-kotlin: Kotlin"
    ```kotlin
      private val client = OkHttpClient()

      fun run() {
        val request = Request.Builder()

   * We get plan2 as a follow-up to plan1, typically retry the same IP but different TLS.
   * We get plan3 as a retry of plan0, which was canceled when it lost the race.
   *
   * This test confirms that we prefer to do the TLS follow-up (plan2) before the TCP retry (plan3).
   * It also confirms we enforce the 250 ms delay in each race.
   */
  @Test
  fun tcpConnectionsRaceAfterTlsFails() {
    val plan0 = routePlanner.addPlan()

 * removeAll} methods, which contain values that have just been removed from the multimap, are
 * naturally <i>not</i> views.
 *
 * <h3>Subinterfaces</h3>
 *
 * <p>Instead of using the {@code Multimap} interface directly, prefer the subinterfaces {@link
 * ListMultimap} and {@link SetMultimap}. These take their names from the fact that the collections
 * they return from {@code get} behave like (and, of course, implement) {@link List} and {@link

     * order in which entries were inserted into the builder, unless {@link #orderEntriesByValue}
     * was called, in which case entries are sorted by value.
     *
     * <p>Prefer the equivalent method {@link #buildOrThrow()} to make it explicit that the method
     * will throw an exception if there are duplicate keys or values. The {@code build()} method
     * will soon be deprecated.
     *

 * guarantees detailed below.
 *
 * <p><b>Warning:</b> avoid <i>direct</i> usage of {@link ImmutableCollection} as a type (just as
 * with {@link Collection} itself). Prefer subtypes such as {@link ImmutableSet} or {@link
 * ImmutableList}, which have well-defined {@link #equals} semantics, thus avoiding a common source
 * of bugs and confusion.
 *