On Monday, 12 January 2015 at 13:25:26 UTC, Adam D. Ruppe wrote:
> On Monday, 12 January 2015 at 11:43:26 UTC, Ola Fosheim Grøstad wrote:
>> Does this mean that D will get fast EH?
>
>
> It is fast already...

What makes you say that? Doesn't D still use the standard zero-cost EH that was created for Itanium, where you take the performance hit on unwinding?

On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote:
> On 1/11/2015 5:06 AM, Dicebot wrote:
>> What is your opinion of approach advertised by various functional languages and
>> now also Rust? Where you return error code packed with actual data and can't
>> access data without visiting error code too, compiler simply won't allow it.
>
> It's a great question. I have a lot of experience with error codes, and with exceptions. I have zero with the packed scheme, though that doesn't stop me from having an opinion :-)
>
> Perhaps I misunderstand, but given A calls B calls C,
>
>    A => B => C

The general solution in functional programming is error chaining.
An example, C is a function that reads in lines of a program and B is a function that takes all those lines and counts words.
C will either return an error or lines and B will either immediately return that error to A or convert the lines to word counts.
This works especially well with function chaining, because you can hide the error propagation in a generic chaining method (called map).

http://danielwestheide.com/blog/2012/12/26/the-neophytes-guide-to-scala-part-6-error-handling-with-try.html

On Monday, 12 January 2015 at 13:54:18 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 12 January 2015 at 13:25:26 UTC, Adam D. Ruppe wrote:
>> On Monday, 12 January 2015 at 11:43:26 UTC, Ola Fosheim Grøstad wrote:
>>> Does this mean that D will get fast EH?
>>
>>
>> It is fast already...
>
> What makes you say that? Doesn't D still use the standard zero-cost EH that was created for Itanium, where you take the performance hit on unwinding?

The advantage of return code / union type error handling is that the exceptional case is as fast as the successful case.

The disadvantage of return code / union type error handling is that the successful case is as slow as the exceptional case.

So which method is faster depends on how exceptional your exceptions are.

On Monday, 12 January 2015 at 16:15:34 UTC, Matthias Bentrup wrote:
> The disadvantage of return code / union type error handling is that the successful case is as slow as the exceptional case.

It is in a register...

On Monday, 12 January 2015 at 13:54:18 UTC, Ola Fosheim Grøstad wrote:
> What makes you say that?

try/throw/catch is like 50x slower than doing nothing except returning a value, but D's exceptions still tend to outperform Java and C#; it isn't awful.

I still wouldn't use them for ordinary flow as a general rule though, but I think they work well for cases where you ask a function to do something and it just can't.

> Doesn't D still use the standard zero-cost EH that was created for Itanium, where you take the performance hit on unwinding?

I don't know, I'm just thinking about the bemchmarks.

Walter Bright <newshound2@digitalmars.com> wrote:
> On 1/11/2015 11:09 PM, Tobias Müller wrote:
>> - Error codes are automatically ignored
>> - Exceptions are automatically propagated
>> 
>> IMO both are not ideal and lead to sloppy programming.
>> Ignoring errors is of course worse than aborting where you could have
>> handled the error.
>> 
>> Rust-style "packed" errors are nice because you are forced to think about the correct handling.
> 
> 
> I don't think this is an answer to my point.

I thought that your question was a rhetorical one and I agree to a certain
degree.
You can still have automatic cleanup though. Rust has RAII.

The point is that I think that trading some prettyness for explicitness is a good thing in that case.

But then again I also like checked exceptions (java) that seem to be disliked by most. It a similar tradeoff.

"weaselcat" <weaselcat@gmail.com> wrote:
> On Monday, 12 January 2015 at 07:09:54 UTC, Tobias Müller wrote:
>> - Error codes are automatically ignored
>> - Exceptions are automatically propagated
>> 
>> IMO both are not ideal and lead to sloppy programming.
>> Ignoring errors is of course worse than aborting where you > could have
>> handled the error.
>> 
>> Rust-style "packed" errors are nice because you are forced to > think about the correct handling.
> 
> There's nothing stopping you from just throwing errors out in Rust(last I used it anyways) via empty match statements and/or unwrap.

But you have to do so explicitly. You cannot just remove every possibility to ignore errors, because sometimes it is justified.

BTW: 'unwrap' panics if it contains an error. But that's not really important here.

On Monday, 12 January 2015 at 17:22:27 UTC, Adam D. Ruppe wrote:
> On Monday, 12 January 2015 at 13:54:18 UTC, Ola Fosheim Grøstad wrote:
>> What makes you say that?
>
> try/throw/catch is like 50x slower than doing nothing except returning a value, but D's exceptions still tend to outperform Java and C#; it isn't awful.
>
> I still wouldn't use them for ordinary flow as a general rule though, but I think they work well for cases where you ask a function to do something and it just can't.
>
>> Doesn't D still use the standard zero-cost EH that was created for Itanium, where you take the performance hit on unwinding?
>
> I don't know, I'm just thinking about the bemchmarks.

Right, I kinda think that C++ EH is awful outside the context of big iron. It is often avoided.

I think a clean language should find one single way to deal with errors, so having one mechanism that performs well would make for clean programming.

I've suggested many alternatives before, at least 4. And D could do anything the hardware supports. Including having multiple return paths, efficient longjump, implicit errorcode propagation, offsetbased unwinding...

Error handling and GC are perhaps the two issues that are the major weak spots for D. I think the language could be changed somewhat and do both reasonably well (as well as one can with stop-the-world-GC).

On Mon, Jan 12, 2015 at 05:22:26PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Monday, 12 January 2015 at 13:54:18 UTC, Ola Fosheim Grøstad wrote:
> >What makes you say that?
> 
> try/throw/catch is like 50x slower than doing nothing except returning a value, but D's exceptions still tend to outperform Java and C#; it isn't awful.

It's a lot better now, but D exceptions used to be orders of magnitude slower than Java's. There's an interesting little history of D exception performance here:

	https://issues.dlang.org/show_bug.cgi?id=9584


> I still wouldn't use them for ordinary flow as a general rule though, but I think they work well for cases where you ask a function to do something and it just can't.

Yeah, exceptions are supposed to be ... well, *exceptions*, rather than the norm. :-) If you're using exceptions to do flow control, you're doing something wrong.

Still, #9584 had some discussions about doing lazy stack trace construction, which was costing most of the time, but I don't remember if that was actually implemented.


T

-- 
We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL

"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
> On Mon, Jan 12, 2015 at 05:22:26PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
>> I still wouldn't use them for ordinary flow as a general rule though, but I think they work well for cases where you ask a function to do something and it just can't.
> 
> Yeah, exceptions are supposed to be ... well, *exceptions*, rather than the norm. :-) If you're using exceptions to do flow control, you're doing something wrong.

But what's exceptional for you is normal for me.

C#'s Dictionary has TryGetValue that returns a bool in addition to the normal indexing operator []  that throws, exactly for that reason. And this is no exception (no pun intended), there are several cases like that in C#. IMO there's something wrong if you have to resort to such code duplification.