The obsession with ErrorOr, TRY() and malloc(8) possibly failing is making our codebase ugly and annoying to work on.

This is basically my fault, since I started the trend by falling in love with TRY() in the kernel and then bringing it to userland without properly considering the cost/benefit.

Meticulous OOM handling and propagation is vital in some contexts, such as:

• Kernel
• Services that accept connections from clients that may misbehave or request too many resources (e.g WindowServer, SystemServer, etc.)
• Library code that interprets untrusted data (e.g image/media decoders)
• Library code that may try to allocate very large amounts of memory (e.g Gfx::Bitmap)

However, I don't believe that we're gaining anything by obsessively worrying about every tiny heap allocation possibly failing.

Also, in complex libraries that are essentially virtual machines like LibWeb, LibJS, and LibPDF, making a meaningful recovery from a tiny OOM is basically impossible. We are better off crashing the program at that point (and keeping the crash contained UI-wise by way of process separation).