Alternatives to exceptions for error handling

[Ola Fosheim Grøstad]

On Monday, 30 November 2020 at 16:02:32 UTC, Andre Pany wrote:
> On Monday, 30 November 2020 at 12:59:32 UTC, Jacob Carlborg 
> wrote:
>> In Ruby there's the `retry` keyword for this. Although you 
>> cannot control the recovery handler from the outside, like in 
>> your example. In D terms you would put `retry` in a `catch` 
>> block and it would run the code inside the `try` block again.

Interesting, I didn't know that.

> In java there is a nice library solution called fail safe: 
> https://jodah.net/failsafe/
>
> Something like that is missing in D (code.dlang.org).

Yes, maybe we could find ideas in high level frameworks.

I guess one simple solution with the current setup would be for 
the caller to provide a "progress object" which is used for 
tracking progress and has resolvers. When it totally fails the 
library can throw the progress-object which is configured to 
indicate the error... Kinda like NSError in Objective C, but more 
active.

But I think it is more forwardlooking to inject depencies based 
on call-tree analysis (interprocedural analysis). Then you can 
get static errors for wrong configuration at compile time.

Anyway, interesting topic. No clear right or wrong. The main 
problem is to get people to agree on protocols, which is why a 
language feature has some merits.