+declare_clippy_lint! {
+ /// **What it does:** Checks for `.expect()` calls on `Option`s.
+ ///
+ /// **Why is this bad?** Usually it is better to handle the `None` case. Still,
+ /// for a lot of quick-and-dirty code, `expect` is a good choice, which is why
+ /// this lint is `Allow` by default.
+ ///
+ /// **Known problems:** None.
+ ///
+ /// **Example:**
+ ///
+ /// Using expect on an `Option`:
+ ///
+ /// ```rust
+ /// let opt = Some(1);
+ /// opt.expect("one");
+ /// ```
+ ///
+ /// Better:
+ ///
+ /// ```rust
+ /// let opt = Some(1);
+ /// opt?;
+ /// ```
+ pub OPTION_EXPECT_USED,
+ restriction,
+ "using `Option.expect()`, which might be better handled"
+}
+
+declare_clippy_lint! {
+ /// **What it does:** Checks for `.expect()` calls on `Result`s.
+ ///
+ /// **Why is this bad?** `result.expect()` will let the thread panic on `Err`
+ /// values. Normally, you want to implement more sophisticated error handling,
+ /// and propagate errors upwards with `try!`.
+ ///
+ /// **Known problems:** None.
+ ///
+ /// **Example:**
+ /// Using expect on an `Result`:
+ ///
+ /// ```rust
+ /// let res: Result<usize, ()> = Ok(1);
+ /// res.expect("one");
+ /// ```
+ ///
+ /// Better:
+ ///
+ /// ```rust
+ /// let res: Result<usize, ()> = Ok(1);
+ /// res?;
+ /// ```
+ pub RESULT_EXPECT_USED,
+ restriction,
+ "using `Result.expect()`, which might be better handled"
+}
+