エラーの無視は、どれだけ目立つか

実演は Docker の aarch64 コンテナで、Go 1.27.1 と rustc 1.98.1 を使いました。どちらも2回実行し、出力は同一でした。

package main
import ("fmt"; "strconv"; "os")
func main() {
	n, _ := strconv.Atoi("12x")
	fmt.Println("n =", n)
	os.Remove("/no/such/file")      // 戻り値を捨てても何も言われない
	fmt.Println("done")
}

vet exit=0
n = 0
done
exit=0

12x は数ではないので Atoi は失敗し、エラーと 0 を返しています。その失敗は _ に消え、n = 0 が正常値として流れました。存在しないファイルの削除も失敗しているはずですが、戻り値ごと捨てた行は何も出していません。

同じことを Rust で書きます。

fn main() {
    "12x".parse::<i32>();
    std::fs::remove_file("/no/such/file");
    let _ = std::fs::remove_file("/no/such/file");
    let n: i32 = "12x".parse().unwrap_or(0);
    println!("n = {}", n);
}

warning: unused `Result` that must be used
--> /w/main.rs:2:5
|
2 |     "12x".parse::<i32>();
|     ^^^^^^^^^^^^^^^^^^^^
|
= note: this `Result` may be an `Err` variant, which should be handled
= note: `#[warn(unused_must_use)]` (part of `#[warn(unused)]`) on by default
help: use `let _ = ...` to ignore the resulting value
|
2 |     let _ = "12x".parse::<i32>();
|     +++++++
 
warning: unused `Result` that must be used
--> /w/main.rs:3:5
|
3 |     std::fs::remove_file("/no/such/file");
|     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this `Result` may be an `Err` variant, which should be handled
help: use `let _ = ...` to ignore the resulting value
|
3 |     let _ = std::fs::remove_file("/no/such/file");
|     +++++++
 
warning: 2 warnings emitted
 
rustc exit=0
n = 0
exit=0

警告は2行目と3行目の2件で、let _ = と書いた4行目には出ていません。警告を消す方法として rustc 自身が let _ = ... を提案しています。そして rustc は exit 0 で、生成されたプログラムは n = 0 を出して終わりました。

Rust で変わったのは、何も書かずに捨てると警告が出る点です。黙って捨てるなら let _ = か unwrap_or(0) のように、捨てたことが読める形を書く必要があります。Rust が足しているのは、警告と、捨てたことが読める目印までです。

なお unwrap と expect は捨てる書き方ではなく、Err のときに panic させる書き方です。Rust Book はこれを試作段階で使い、後でエラー処理を書くときの目印になるものとして紹介しています(They leave clear markers in your code for when you’re ready to make your program more robust.)。

Python 3.14.7 です。

import json
def load(s):
    try:
        return json.loads(s)["n"]
    except Exception:
        return 0
print(load('{"n": 5}'), load('{"m": 5}'), load('not json'))
int("12x")
print("unreached")

5 0 0
Traceback (most recent call last):
File "/w/a.py", line 8, in <module>
  int("12x")
  ~~~^^^^^^^
ValueError: invalid literal for int() with base 10: '12x'
exit=1

{"m": 5} は JSON としては正しく、キーが違うだけです。not json は読めもしません。別々の2つの失敗が、同じ 0 になりました。 捕まえなかった int("12x") のほうは traceback を出し、unreached を出さずに exit 1 で止まっています。

Node v24.21.0 です。

async function f() { throw new Error("boom"); }
try { f(); } catch (e) { console.log("caught?", e.message); }
console.log("after try");

after try
file:///w/a.mjs:1
async function f() { throw new Error("boom"); }
                         ^
 
Error: boom
  at f (file:///w/a.mjs:1:28)
  at file:///w/a.mjs:2:7
  at ModuleJob.run (node:internal/modules/esm/module_job:561:25)
  at async node:internal/modules/esm/loader:647:26
  at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:101:5)
 
Node.js v24.21.0
exit=1

caught? は一度も出ていません。after try が先に出て、そのあと Error: boom で exit 1 です。try の中で f() は正常に Promise を返しており、誰も受け取らなかった reject を Node が検出したのは after try の後だったことが、出力の順番に表れています。

落ちたのは言語仕様ではなく Node の設定によるものです。v24 の CLI 文書は --unhandled-rejections の既定 throw を If this hook is not set, raise the unhandled rejection as an uncaught exception. This is the default. と書き(unhandledRejection のハンドラが無ければ uncaught exception にする)、履歴に v15.0.0 Changed default mode to throw. Previously, a warning was emitted. とあります。同じコードを --unhandled-rejections=warn で動かすと、警告を2件出して exit 0 で続きました。その警告文は原因を throwing inside of an async function without a catch block と名指ししています。