It doesn't have to be that different with exceptions, which were invented for that very reason. When used properly, you catch those at the highest appropriate l

It doesn't have to be that different with exceptions, which were invented for that very reason. When used properly, you catch those at the highest appropriate level by letting them "bubble up". What is different though, is that exceptions are much more implicit. In most programming environments, it isn't clear which ones might occur. Java has checked exceptions to counter that, but according to many it's a cure worse than the disease. In that sense, "railway-oriented programming" supposedly offers the best of both worlds. Personally, I'm not entirely convinced, though. In practice, exceptions will still occur unless the language doesn't have them, so now you have two mechanisms to deal with errors. (.NET has a strong culture of exceptions—no thank you to lots of wrappers to make established libraries use result types.) Also, it doesn't seem realistic to anticipate every possible error scenario. Sometimes all you know is that something went wrong. That's fine. Show a generic error and improve the software once the cause has been identified. Still, I would like there to be a better way to find out about the most common exceptions than reading documentation.