> The question is why the language does have this kind of manual error handling as a standard in the first kind. Probably for the same reason Rust does, and wh

> The question is why the language does have this kind of manual error handling as a standard in the first kind. Probably for the same reason Rust does, and why it suffers much the same problem: 1. It is what was in vogue in the 2010s. 2. More importantly, the problem isn't limited to errors. What have you gained treating errors as some hyper special case when they aren't any different than any other value? I think we agree that we can do better, but seeing errors as special doesn't get you there. We need something that understands the all-encompassing problem. So, failing that understanding, if you're going to do something that sucks, you may as well choose the least-sucky option, surely? Exception handling brings a horrible developer experience. To the point that in languages where errors over exception handling semantics are the norm, you will find that most developers simply give up on error handling entirely because it is so painful. > Some library that behaves completely differently from the rest of the language and breaks all interop with the rest of the ecosystem will have a hard time gaining traction I'm not sure history agrees. Ruby was also of the return values over exception handling mind before Rails came along. Rails pushed exception handlers for errors and developers went for it. Provide an API people actually want to use, and they'll use it. What was common before is inconsequential. I expect what you are really saying is that exception handling wouldn't actually improve this example case even in the best case, and in the worst case developers would end up giving up on error handling leaving such a package to be a net negative to a codebase.