Jump to page: 1 2 3
Thread overview
[OT] Is there a real alternative to exceptions ?
Jan 16
Basile B.
Jan 16
monkyyy
Jan 16
Basile B.
Jan 16
monkyyy
Jan 17
Kagamin
Jan 17
Basile B.
Jan 17
Kagamin
Jan 17
Kagamin
Jan 16
Basile B.
Jan 16
Dom DiSc
Jan 17
Basile B.
Jan 16
Dennis
Jan 17
Meta
Jan 17
Basile B.
Jan 17
monkyyy
Feb 03
Mensikovk
5 days ago
Manu
4 days ago
Ali Çehreli
January 16

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.

January 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)
January 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:

>

[...]

  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)

I dont see how that helps to abort when an error happens "in between the chain" let's say.

January 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.

Sum types?

January 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:

>

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?

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 ?

January 16

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:

>

On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:

>

[...]

  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)

I dont see how that helps to abort when an error happens "in between the chain" let's say.

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)

January 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.

January 16

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

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.

January 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).

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 😛

January 17

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 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.

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.

« First   ‹ Prev
1 2 3