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