Good afternoon, Larry. Looking at the comparison table, it seems that the two most important differences are:
1. Backtrace consumes a lot of resources. 2. There is an explicit contract for exceptions thrown by a function. 3. I didn't fully understand the point about the exception hierarchy, but it seems important too. It seems to me that the Backtrace issue is a problem of a low level of abstraction — the implementation of exceptions. That's one problem. The lack of an explicit contract is a problem on a completely different level of abstraction. The issue with the missing contract could have been solved even for exceptions, without creating a new entity. Regarding Backtrace, the following questions seem fair: 1. What if I want to know where the situation occurred? Can I just ignore this information? 2. If yes, why not create an option to disable backtrace generation for exceptions? Regarding the Result/Error type. I have experience using this approach in remote services, where exceptions seem inappropriate. It’s probably possible to use it even now without generics, and without any special language features. What if we focus on: 1. Improving exception handling, making it as lightweight as in Python. 2. Introducing explicit exception contracts. Best Regards, Ed.
