Comments by "Mikko Rantalainen" (@MikkoRantalainen) on "Why I Prefer Exceptions To Errors" video.

The whole article seems to mistake retuning error values as "returning error as 8 bit int". If your only error value is a 8 bit int, sure, that's a pretty bad abstraction.
1
0:15 If "returning errors as values" means "my function return value is int and it's zero if everything went okay and error code if something failed", sure, I like exceptions better. However, if the return value is something like Result in Rust, give me return values any day. And give me a nice shortcut to handle those like the "?" shorthand in Rust. The problem with exceptions (e.g. C++) is that when see code like void function foo() { bar(); zoo(); baz(); } Is this function correctly implemented? Can it throw? What if zoo() throws? You cannot know by reading the source code! And if you cannot know the behavior of a function even if you see its full implementation, you'll have problems in long run.
1
9:07 If you have non-shared in-memory state in stack only and follow RAII model, you can safely use exceptions. However, that's a HUGE if and rarely happens in reality if you look at the codebase accurately. And that assumption is never ever true for any old codebase and there's no sane way to start using exceptions after the fact when your codebase is already unsafe for exceptions.
1
22:15 I think the author is arguing here that when you change your program to introduce new error case (throw from a function that didn't use to throw) it's a nice thing(?) to not change the signature. Isn't that argument basically saying that I don't care if anybody is able to anything sensible with my newly introduced error case? How is that supposed to result in improved stability or higher software quality? I much prefer the Rust way where change in interface (hey, this thing can now throw errors instead of being successful every time) requires the calling code to actually handle that error.
1
26:55 It's not possible to handle OOM Killer from regular program. Once kernel OOM Killer chooses your process, you get zero additional CPU instructions before the process is killed. Try handling that! The best you can do is to put critical processes in cgroup and add a custom OOM handler for that group. However, if your process is critical realtime process, that's not a real option for you.
1
Using C and errno as an explanation why ALL returned error values are bad is a strawman if there ever was one. C and errno was probably high tech in 1975 but we have already understood that it wasn't the best interface you can create.
1
22:27 I would argue that Rust made a mistake when they ever added unwrap(). I think it should be called unsafe_unwrap() or something like that because well written code shouldn't use it.
1