This is silly. We can avoid stack overflow by avoiding unbounded recursion.

In user-space, memory overcommit means that we will almost or literally never see an out of memory error.

In kernel space and other constrained environments, we can simply check for allocation, failure and handle it accordingly.

This is a terrible argument for treating all code as potentially failing with any possible error condition.

Rust and GO has panics for these. Most of the time there is nothing application can do by itself, either there is a bug in application or there is actually shortage of memory and only the OS can do anything about it.

I'm not talking about embedded or kernels. Different stories.

^^^ - This - my recent one, came to the realization that dealing with memory mapped files is much harder without exceptions (not that exceptions make it easier, but at least possible).

Why? Let's say you've opened a memory mapped file, you've got pointer, and hand this pointer down to some library - "Here work there" - the library thinks - oh, it's normal memory - fine! And then - physical block error happens (whether it's Windows, OSX, Linux, etc.) - and now you have to handle this from... a rather large distance - where "error code" handling is not enough - and you have to use signal handling with SIGxxx or Windows SEH handling, or whatever the OS provides

And then you have languages like GoLang/Rust/others where this is a pain point (yes you can handle it), but how well?

If you look in ReactOS the code is full with `__try/__except` - https://github.com/search?q=repo%3Areactos%2Freactos+_SEH2_T... - because user provided memory HAVE to be checked - you don't want exception happening at the kernel reading bad user memory.

So it's all good and fine, until you have to face this problem... Or decide to not use mmap files (is this even possible?).

Okay, I know it's just a silly little thing I'm pointing here - but I don't know of any good solution off hand...

And even handling this in C/C++ with all SEH capabilities - it still sucks...

> Every function can fail with StackOverflowError and you can't do anything about it.

> Almost every function can fail with OutOfMemoryError and you can't do anything about it.

In fact we can - though rarely do - prove software does not have either of these mistakes. We can bound stack usage via analysis, we usually don't but it's possible.

And avoiding OOM is such a widespread concern that Rust-for-Linux deliberately makes all allocating calls explicitly fallible or offers strategies like Vec::push_within_capacity a method which, if it succeeds pushes the object into the collection, but, if it's full rather than allocate (which might fail) it gives back the object - no, you take it.

Checked exceptions are not very different from the Result type in that regard TBH.

This is the "I don't care what fails nor do I wish to handle them" option. Which for some use cases may be fine. It does mean that you don't know what kinds of failures are happening nor what the proper response to them is, though. Like it or not errors are part of your domain and properly modeling them as best you can is a part of the job. Catching at the top level still means some percentage of you users are experiencing a really bad day because you didn't know that error could happen. Error modeling reduces that at the expense of developer time.

Even better: just let it crash an get a core dump with full context information rather than some log missing information.

But often some "expected" errors can be handled in some way better (retry, ask user, use alternate approach, ...)

Maybe you are not giving that up, but you are giving up doing memory management "properly", i.e. use more memory and CPU time than necessary for convenience.

Maybe this is my Golang dev leaking, but I intuitively thought that `try: / except:` in Python is essentially the same thing as `if err != nil`, just my IDE doesn't scream at me if I don't catch them.

I suspect too much is broken (well, I'd say more clearly "crap") in C++ to be sure whether any particular core ideas hold up based on that whole language.

I'm particularly mindful of C++ 26 Erroneous Behaviour for initialization. This idea was introduced for the forthcoming C++ 26 language version, it says that although just making a variable `int k;` and then later taking its value is an error, it's no longer Undefined Behaviour, the compiler shall arrange that it has some specific value.

This is a meaningful improvement over the C++ status quo. But, that doesn't mean the core idea is actually good. It's bad to do this in your language, they didn't have any better choice for C++ for historical reasons so this was the least bad option.

Agreed, and I wish there were more emphasis on ensuring panic free sections of Rust code.

Is there a language that has proper exclusively checked exceptions? That is, not just syntax sugar around checking an error value (à la Swift), but actual “the processor signals an exception” semantics, but all exceptions are still enforced to be handled-or-passed by the compiler?

Honest question, because I can’t think of any. I can see it being advantageous to have checked-only exceptions but there has to be a good reason why it’s so rare-to-never that we see it.

I’m not sure how else you’d get the holy grail, which I’d define as:

1. The compiler enforces that you either handle an exception or pass it to the caller

2. Accurate and fine-grained stack traces on an error (built-in, not opt-in from some error library du jour)

3. (ideally) no runtime cost for non-exception paths (no branches checking for errors, exceptions are real hardware traps)

C++ has 2 and 3, Java has only 2 (because RuntimeException exists), Rust has only 1. I’d love a language with 1 and 2, but all 3 would be great.