Because the only way it is not ever a maintenance nightmare is when you really don't care that function execution could be aborted at any point without any visual clue. And the only way I can see you wouldn't care is when you go 100% in to everything-context managed / RAII or similar. And that again, sorry but I can't be arsed to prematurely rip everything into little pieces like that. It makes for terrible code IMO.

And from my own experience, no I don't have to check a lot of return values.

It's not signalling which has been shown to be a complete mistake, but checked exceptions, more specifically as implemented by Java.

Signalling works just fine and is actually rather enjoyable when done well.

Rust, Swift, Erlang, Haskell, ...

> What has "signaled exceptions"?

Java.

It's not clear what you're asking.

My comment noted that signalling the possibility of errors to caller (in general) is valuable.

jcelerier objected with java's checked exceptions as a counter-example, as they signal to the caller, but they're shit.

However that's not a counter example, that's just java's checked exceptions being a shitty implementation of the idea.