digitalmars.D - [OT] Is there a real alternative to exceptions ?
- Basile B. (11/11) Jan 16 I have the feeling that things like
- monkyyy (8/19) Jan 16 1) add a error code system to the range api
- Basile B. (3/12) Jan 16 I dont see how that helps to abort when an error happens "in
- Derek Fawcus (2/13) Jan 16 Sum types?
- Basile B. (8/25) Jan 16 That's not the problem. remember the example
- Dom DiSc (5/10) Jan 16 So, why don't keep using exceptions?
- Basile B. (4/16) Jan 17 I should have said it earlier but the context is another
- Dennis (7/8) Jan 16 [The Easiest Way To Handle Errors Is To Not Have
- Meta (5/12) Jan 16 It's very easily doable, arguably with even better ergonomics
- Basile B. (3/17) Jan 17 Nice, thanks for the link, so finally it seems that the problem
- Paulo Pinto (5/19) Jan 17 Some may be, others go with the times, courtesy of C++23.
- Paolo Invernizzi (4/15) Jan 17 I suggest to you to have a look how pure functional programming
- monkyyy (4/23) Jan 17 While they should be part of the convrsation; purity is holding
- Mensikovk (13/24) Feb 03 Koka programming language has cool effect system. Its powerful as
I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`. that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors. I'll be interested to read your thoughts on that topic.
Jan 16
On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`. that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors. I'll be interested to read your thoughts on that topic.1) add a error code system to the range api 2) damn the consequences have fail safe functions(1/0==int.max) 3) store errors and extra control flow in my `innate` pattern 4) nullable everywhere, range functions can react to nullable elements 5) preallocate some space for exceptions, cap the size of exception objects(assuming this is about betterc)
Jan 16
On Thursday, 16 January 2025 at 19:13:38 UTC, monkyyy wrote:On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:I dont see how that helps to abort when an error happens "in between the chain" let's say.[...]1) add a error code system to the range api 2) damn the consequences have fail safe functions(1/0==int.max) 3) store errors and extra control flow in my `innate` pattern 4) nullable everywhere, range functions can react to nullable elements 5) preallocate some space for exceptions, cap the size of exception objects(assuming this is about betterc)
Jan 16
monkyyy <crazymonkyyy gmail.com> On Thursday, 16 January 2025 at 19:37:36 UTC, Basile B. wrote:On Thursday, 16 January 2025 at 19:13:38 UTC, monkyyy wrote:aborts are bad; hottake; nullables are far far better pattern But 3 and 5 could be the same "bad goto" as exceptions with compiler help or some truly awful raw asm 3 could also abort on error with lib design, but that would be very ugly --- ``` nullable!int inverse(int i){ if(i==0){return null;} return 100/i; } [2,0,5,4].map!inverse.sort==[null,20,25,50]; ``` Could just exist, theres one of them eagerness vs lazyness tradeoffs here between eager exceptions and lazy nullables; Im very much in favor of the later and never use exceptions as intended(when phoboes throws, make an hack to make it go away)On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:I dont see how that helps to abort when an error happens "in between the chain" let's say.[...]1) add a error code system to the range api 2) damn the consequences have fail safe functions(1/0==int.max) 3) store errors and extra control flow in my `innate` pattern 4) nullable everywhere, range functions can react to nullable elements 5) preallocate some space for exceptions, cap the size of exception objects(assuming this is about betterc)
Jan 16
On Thursday, 16 January 2025 at 19:37:36 UTC, Basile B. wrote:I dont see how that helps to abort when an error happens "in between the chain" let's say.Turn all operations into monadic combinators, example for Nullable: https://dlang.org/phobos/std_typecons.html#apply
Jan 17
On Friday, 17 January 2025 at 08:43:00 UTC, Kagamin wrote:On Thursday, 16 January 2025 at 19:37:36 UTC, Basile B. wrote:Yeah that's also what's described in the talked pointed by Meta.I dont see how that helps to abort when an error happens "in between the chain" let's say.Turn all operations into monadic combinators, example for Nullable: https://dlang.org/phobos/std_typecons.html#apply
Jan 17
Nullable having range interface, maybe you can just add error to
the range contract?
```
V op(Range)(Range r)
{
if(r.hasError)return r.error;
...
}
```
Jan 17
Or an error subrange?
```
V op(Range)(Range r)
{
if(!r.error.empty)return r.error;
...
}
```
Jan 17
On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`. that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors. I'll be interested to read your thoughts on that topic.Sum types?
Jan 16
On Thursday, 16 January 2025 at 19:38:45 UTC, Derek Fawcus wrote:On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:That's not the problem. remember the example ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` the problem is about keeping the same expressivity but eventually using another error handling system.For example imagine an error happens during the mapping, then what has to do the reducer ?I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`. that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors. I'll be interested to read your thoughts on that topic.Sum types?
Jan 16
On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system.So, why don't keep using exceptions? If you're concerned about GC, try -preview=dip1008 For me this works like a charm.
Jan 16
On Thursday, 16 January 2025 at 23:04:20 UTC, Dom DiSc wrote:On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:I should have said it earlier but the context is another programming language than D. At the moment it has no builtin error handling system.I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system.So, why don't keep using exceptions? If you're concerned about GC, try -preview=dip1008 For me this works like a charm.
Jan 17
On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:I'll be interested to read your thoughts on that topic.[The Easiest Way To Handle Errors Is To Not Have Them](https://www.rfleury.com/p/the-easiest-way-to-handle-errors?utm_source=publication-search) I don't have a general solution for your abstract formulation of the problem, but if you give examples of concrete mapper functions that you think have to throw an exception, I can give you my take on how to avoid it.
Jan 16
On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`.It's very easily doable, arguably with even better ergonomics than with exceptions: https://fsharpforfunandprofit.com/rop/ C/C++ programmers are just stuck in the 80s 😛
Jan 16
On Friday, 17 January 2025 at 00:21:35 UTC, Meta wrote:On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:Nice, thanks for the link, so finally it seems that the problem would be solved since 2014.I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`.It's very easily doable, arguably with even better ergonomics than with exceptions: https://fsharpforfunandprofit.com/rop/ C/C++ programmers are just stuck in the 80s 😛
Jan 17
On Friday, 17 January 2025 at 00:21:35 UTC, Meta wrote:On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:Some may be, others go with the times, courtesy of C++23. https://en.cppreference.com/w/cpp/utility/expected https://en.cppreference.com/w/cpp/utility/optional https://en.cppreference.com/w/cpp/rangesI have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`.It's very easily doable, arguably with even better ergonomics than with exceptions: https://fsharpforfunandprofit.com/rop/ C/C++ programmers are just stuck in the 80s 😛
Jan 17
On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`. that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors. I'll be interested to read your thoughts on that topic.I suggest to you to have a look how pure functional programming languages are handling such kind of constructs. As a soft start I suggest Elm.
Jan 17
On Friday, 17 January 2025 at 09:35:03 UTC, Paolo Invernizzi wrote:On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:While they should be part of the convrsation; purity is holding back ranges and we dont have the compiler tool set of haskell.I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`. that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors. I'll be interested to read your thoughts on that topic.I suggest to you to have a look how pure functional programming languages are handling such kind of constructs. As a soft start I suggest Elm.
Jan 17
On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:I have the feeling that things like ``` a.map!(mapperFun).reduce!(reducerFun).array; ``` is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`. that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors. I'll be interested to read your thoughts on that topic.Koka programming language has cool effect system. Its powerful as monads, but pretty simple. In D there is already the beginning of this system: pure, safe, nogc, nothrow. But in koka they are polymorphic. Also, these koka effects allow you to implicitly configure modules with the necessary callbacks. These effects also allow you to implement async/await, exceptions, generators, and some programs with complex flow control at the program level without having to change the compiler. https://koka-lang.github.io/koka/doc/book.html#sec-effect-types . If you add them to D, then you can transfer many D features to the runtime library altogether.
Feb 03