On Thu, Feb 24, 2022 at 06:02:31AM +1300, rikki cattermole via Digitalmars-d wrote:
> On 24/02/2022 5:59 AM, IGotD- wrote:
> > The Herb Sutter exception/return value proposal would live alongside with the old exceptions. I suspect that D would do the same thing.
> 
> Yes, with the possibility of having the compiler swap the runtime unwinding stuff for value based where possible.
> 
> Apart from some situations where you need to be able to store a class based exception, I don't see why it couldn't work like this.

If we had by-value exceptions, we can implement the current by-reference exceptions simply by treating the reference to the allocated exception as the value to be thrown. I.e.,

	throw new Exception(...);

is equivalent to:

	struct S {
		Exception e;
	}
	Exception e = new Exception(...);
	throwByValue S(e);

So if we implemented by-value exceptions, we don't have to break any existing code, just treat `throw new SomeException` as syntactic sugar for some analogue of the above.


T

-- 
PNP = Plug 'N' Pray

On Wednesday, 23 February 2022 at 16:37:34 UTC, rikki cattermole wrote:
>
> Okay that is easily rectified, we simply allow inheriting from the function body, not just called functions ;)
>
> The reason it must support be declared in some form (which is how it is also represented in the AST) is due to it being value type. Its like as if you put a algebraic type for the return value with your declared return value + what can be thrown from it.

You have a point there but it kind of depends what the design looks like. For example if only one system wide structure is used for value exceptions then you don't need to declare it for every function.

On Wednesday, 23 February 2022 at 14:26:41 UTC, matheus wrote:
> Just saw this today:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html
>
> Seems relevant to any System Language like D that features Exceptions.
>
> Matheus.

This is an interesting paper, but I'm not sure where they are going with it.

Exception are expensive. They need to be used to handle unexpected things. That's kind of in the name. Things that happen often are not exceptional.

Pretty much all workaround they look at incur some performance penalty on the happy path, but this is not a bug, this is a feature. Exceptions are very cheap when not thrown, very expensive when thrown. This is what you want when handling a situation that is exceptional.

The perf they measure for std::expect would be worth investigating. Why is it slow?

> Support struct based exceptions (value type), passed on stack (and hence RC support) as part of the return value of a function.


Who will allocates that (the RC part)?

I personally disagree with the idea of exceptions altogether..


The answer is in solutions like in Zig/Go, errors, multiple return values, if changing the way error handling works in D, better make it good, for good!

There is no reason to be stuck with exceptions..

I moved away from them completly in C++, i wish i could do the same with D..

On Wednesday, 23 February 2022 at 17:14:53 UTC, H. S. Teoh wrote:
> On Thu, Feb 24, 2022 at 06:02:31AM +1300, rikki cattermole via Digitalmars-d wrote:
>> On 24/02/2022 5:59 AM, IGotD- wrote:
>> > The Herb Sutter exception/return value proposal would live alongside with the old exceptions. I suspect that D would do the same thing.
>> 
>> Yes, with the possibility of having the compiler swap the runtime unwinding stuff for value based where possible.
>> 
>> Apart from some situations where you need to be able to store a class based exception, I don't see why it couldn't work like this.
>
> If we had by-value exceptions, we can implement the current by-reference exceptions simply by treating the reference to the allocated exception as the value to be thrown. I.e.,
>
> 	throw new Exception(...);
>
> is equivalent to:
>
> 	struct S {
> 		Exception e;
> 	}
> 	Exception e = new Exception(...);
> 	throwByValue S(e);
>
> So if we implemented by-value exceptions, we don't have to break any existing code, just treat `throw new SomeException` as syntactic sugar for some analogue of the above.
>
>
> T

I am sorry but this feels like "hiding my problems under the carpet" type of solution.. it is not very elegant..

If the fundamentals of the feature are to be rethought / redesigned because considered harmful (performance penalty is harmful, at least to me), then the users must be prepared and educated, so they understand the motive of a potential change, and can design APIs with that in mind!


That is how we build future proof libraries, and not "oh, i now need to port all that code to a newer language with newer constructs" kind of situations..


It's not like the world depends on D, it's a niche market, we could, and we should use that to our advantage and move forward, without being scared of hurting some people, we can still have a long upgrade path, with a solid deprecation model, and some static analysis tools in case we still need to depend on a library that uses the old model..


C didn't need any of that, reason why it is universally adopted, languages depend on it, and is still kicking today!

So the question is why should we even need exceptions? let's continue the idea that D is the natural evolution of C, and improve on its error handling model with better way to represent error codes instead!

My 2 cents..


Sorry for the consecutive posts btw.. :D

On Thursday, 24 February 2022 at 00:19:44 UTC, meta wrote:
> Who will allocates that (the RC part)?
>
> I personally disagree with the idea of exceptions altogether..
>
>
> The answer is in solutions like in Zig/Go, errors, multiple return values, if changing the way error handling works in D, better make it good, for good!
>
> There is no reason to be stuck with exceptions..

There are reasons to be stuck with exceptions. Go is a no go, due to constant if else error checking it forces user to do. Exceptions perfectly represent exceptional cases that can be handled if caller wants to. Littering every method with tuples as return values and method calls with if checking is even worse than performance costs of how currently exceptions are implemented.

The point is, not all code is required to be performant, some of it, can use exceptions for code and logic readability at cost of performance downgrade.

I did a double take and thought I had somehow replied to this thread and forgot about it. This forum ain't big enough for the two of us 😛

On Thursday, 24 February 2022 at 00:52:56 UTC, Meta wrote:
> I did a double take and thought I had somehow replied to this thread and forgot about it. This forum ain't big enough for the two of us 😛

sorry :D


> There are reasons to be stuck with exceptions. Go is a no go, due to constant if else error checking it forces user to do.

I agree, but it is getting better! Also the idea is to not mimic them, but to learn from them instead and move forward..

On Thursday, 24 February 2022 at 01:04:47 UTC, meta wrote:
>> There are reasons to be stuck with exceptions. Go is a no go, due to constant if else error checking it forces user to do.
>
> I agree, but it is getting better! Also the idea is to not mimic them, but to learn from them instead and move forward..

Sure, D should be taking best parts from other languages and improve them. It's just, that having no exceptions, and no alternative as good as them or better, might not be the best idea. I personally don't care how exceptions are implemented under the hood as long as they   do their job well enough for staple source code (non-perf chunks of the code). Performance sensitive code should just use more performant alternatives to exceptions.

Imho, nicest option would be to provide ability to choose what implementation of exception mechanism a function uses. Then for function expected to fail often, you could choose to propagate the exception through as part of return argument, or any other mechanism that is performing better at cost of non-exception path.