CHECK should be used for logic errors, not genuine runtime errors. This is true for build tools as well as for Chrome. In the worst case the use of a CHECK can, apparently, cause a build to succeed when it should fail, as shown below:

> ninja chrome -j 960 -l 48
[1 processes, 1/1 @ 0.3/s : 3.337s ] Regenerating ninja files
[960 processes, 2623/22981 @ 61.0/s : 42.994s ] CXX obj/media/filters/filters/ffmpeg_video_decoder.obj
wineserver: could not save registry branch to user.reg : Device or resource busy
[1 processes, 22961/22971 @ 54.3/s : 422.495s ] ACTION //tools/v8_context_snapshot:generate_v8_context_snapshot(//build/toolchain/win:win_clang_x64)
[0723/145133.979:FATAL:v8_context_snapshot_generator.cc(70)] Check failed: 0 < base::WriteFile(file_path, blob.data, blob.raw_size) (0 vs. -1)
Backtrace:
        base::debug::StackTrace::StackTrace [0x00007FF6DB5C5404+36] (C:\src\chromium3\src\base\debug\stack_trace_win.cc:286)
        logging::LogMessage::~LogMessage [0x00007FF6DB445ED5+101] (C:\src\chromium3\src\base\logging.cc:593)
        main [0x00007FF6DA711155+341] (C:\src\chromium3\src\tools\v8_context_snapshot\v8_context_snapshot_generator.cc:72)
        __scrt_common_main_seh [0x00007FF6DCB8EDE8+268] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283)
        BaseThreadInitThunk [0x00007FFFA2CE1FE4+20]
        RtlUserThreadStart [0x00007FFFA3D7CB31+33]

[1 processes, 22969/22969 @ 50.0/s : 459.503s ] STAMP obj/chrome/chrome.stamp

The CHECK failed, presumably due to having a test process open in a debugger, thus locking the file. A just-in-time debugger dialog popped up and a chose a Visual Studio instance to debug the crash. Already this is misleading because a crash implies a tool bug when in fact the problem was just a locked file.

After examining the failure in the debugger I closed the debugger and I *guess* the process exited with an error code of zero, meaning that the build continued, despite not having written the file!