Re: Concept: Lightweight error channels

On Sun, Apr 27, 2025, at 10:16, Edmond Dantes wrote: > 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. I'm not going to lie, I spent nearly an hour last night attempting to create an exception without a stack trace. I was quite surprised at how *impossible* it is. The engine really goes out of its way to ensure the trace is set. A simple solution (for this problem) may be creating a new exception type \LightException or something that would allow for never setting a stack trace. This is pretty heavily on the "pragmatic" side of the solution space, but it is also relatively simple. — Rob