On Sun, 27 Apr 2025 at 10:27, Rob Landers <rob@bottled.codes> wrote: > > 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: > > Backtrace consumes a lot of resources. > > There is an explicit contract for exceptions thrown by a function. > > 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: > > What if I want to know where the situation occurred? Can I just ignore this > information?
For the type of failure we are talking about, there is not really the need for a backtrace. > > 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: > > Improving exception handling, making it as lightweight as in Python. > > 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. One thing you can do is throw the same exception again. Not really a good solution though. > > 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. The main obstacle here is interface Throwable which promises to have a file, line number and backtrace. Currently you can only throw objects that implement Throwable. https://3v4l.org/LHhNm If we introduce a "LightException", it cannot really extend Exception, because then it gets all the baggage. The solution could be a new interface "Catchable" or "Raisable". But this would be superfluous. Instead, we could allow to throw any objects, or introduce a new keyword "raise", that would allow any objects. On the implementing side, a "raise new NotFound(..)" seems mostly the same as "throw new NotFound(..)". On the declaration side, we might want to add " ... throws NotFound" or "... raises NotFound", to make this part of the contract. So this would be very similar to checked exceptions as I know them from Java. On the calling (and handling) side, any alternative we find to "try ... catch (...) ..." might also be useful for regular exceptions. In fact this would be the big difference to current exceptions and return values in terms of developer experience, whereas the "no stack trace overhead" is more an internal thing. --- Andreas > > — Rob
