On 1/11/2015 2:48 AM, Walter Bright wrote:
> However, if exceptions are thrown for errors instead, the programmer has to
> deliberately add code if he wishes to ignore the error.

Interesting that this article just appeared:

  https://blog.golang.org/errors-are-values

by Rob Pike on error handling in Go. He concludes with:

  "But remember: Whatever you do, always check your errors!"

Which sums up why exceptions are better!

On Wednesday, 14 January 2015 at 00:38:21 UTC, Walter Bright wrote:
> On 1/11/2015 2:48 AM, Walter Bright wrote:
>> However, if exceptions are thrown for errors instead, the programmer has to
>> deliberately add code if he wishes to ignore the error.
>
> Interesting that this article just appeared:
>
>   https://blog.golang.org/errors-are-values
>
> by Rob Pike on error handling in Go. He concludes with:
>
>   "But remember: Whatever you do, always check your errors!"
>
> Which sums up why exceptions are better!

But checked exceptions are definitely not.

On Wednesday, 14 January 2015 at 00:24:41 UTC, Ola Fosheim Grøstad wrote:
> I don't see the problem. I'm suggesting value semantics, it can be copied.
>

Then you can't catch by super class. This is not going to fly.

>> When you are in the catch, you are not unwinding anymore. You could indeed loose chaining to be able to reuse the memory, that is not what is slow when it come to exception, so it won't make it fast.
>
> You can't have chaining with this scheme...? But since you can only have one instance it has to be initialized with value semantics. It's a small constraint.
>

You write that paragraph like there is some logical links between elements in it, but there is none.

> Not using regular Itanium-style unwinding will make it potentially faster.

The only things that is sure here is that it is going to make the non exception path slower. Without specific we can say anything else than that.

> Using TLS makes it possible to propagate over non-D code or code where the register pressure is high,

It won't help with register pressure. Having a pointer to an exception object in a register is equivalent to having a pointer to a TLS memory area in a register.

> it can be optimized away so you don't need TLS if you don't span over non-D code.
>

Without specifics, it is another instance of the sufficiently smart compiler running gag.

> Non D functions can cast by setting the TLS memory to an exception value, then do a regular return. The D function that called the non-D function will check TLS memory to see if there is an exception in flight.
>

You don't make things faster by making the calling convention easier. There is chance that this is gonna fly any better than a flat iron.

On Wednesday, 14 January 2015 at 00:40:10 UTC, Meta wrote:
> On Wednesday, 14 January 2015 at 00:38:21 UTC, Walter Bright wrote:
>> On 1/11/2015 2:48 AM, Walter Bright wrote:
>>> However, if exceptions are thrown for errors instead, the programmer has to
>>> deliberately add code if he wishes to ignore the error.
>>
>> Interesting that this article just appeared:
>>
>>  https://blog.golang.org/errors-are-values
>>
>> by Rob Pike on error handling in Go. He concludes with:
>>
>>  "But remember: Whatever you do, always check your errors!"
>>
>> Which sums up why exceptions are better!
>
> But checked exceptions are definitely not.

http://www.artima.com/intv/handcuffs.html

The best sum up of checked exception you'll find.

>
> http://www.artima.com/intv/handcuffs.html
>
> The best sum up of checked exception you'll find.
>

False.

Unless you mean 'the best sum up of the problems people have with checked exceptions' - it gives a good description of how use of checked exceptions often goes wrong.

For those of us that regularly use checked exceptions, these are known problems and easily worked around.  Some are not problems but features (i.e. ignoring them is painful and obvious).

Granted, a better solution to the problem may be able to avoid problems all together.  But as discussed in this newsgroup before, no better solution presents itself.


NB: It also seems to have a very skewed view of how to handle errors (exceptions) that come up, preferring to just throw everything up to one handler instead of dealing with at the proper abstraction level.  This may be appropriate for certain systems but is not a good strategy in general. If you are doing this then you will likely not see the advantages of checked exceptions.

On Wednesday, 14 January 2015 at 02:40:20 UTC, Jeremy Powers via Digitalmars-d wrote:
>>
>> http://www.artima.com/intv/handcuffs.html
>>
>> The best sum up of checked exception you'll find.
>>
>
> False.
>
> Unless you mean 'the best sum up of the problems people have with checked
> exceptions' - it gives a good description of how use of checked exceptions
> often goes wrong.
>

Full stop. I made that mistake myself various time, so I can talk from experience here.

This is a completely wrong mindset. If people have problem with checked exception, then there IS a problem with checked exception, not people. You won't be able to change people, so you'd better focus on changing checked exceptions.

On Wednesday, 14 January 2015 at 01:37:46 UTC, deadalnix wrote:
> On Wednesday, 14 January 2015 at 00:24:41 UTC, Ola Fosheim Grøstad wrote:
>> I don't see the problem. I'm suggesting value semantics, it can be copied.
>>
>
> Then you can't catch by super class. This is not going to fly.

I said value. Use bitmasks. Class hierarchies don't work very well.

>> You can't have chaining with this scheme...? But since you can only have one instance it has to be initialized with value semantics. It's a small constraint.
>>
>
> You write that paragraph like there is some logical links between elements in it, but there is none.

If you cannot follow the logic... Where did you get lost?

> The only things that is sure here is that it is going to make the non exception path slower. Without specific we can say anything else than that.

?

You essentially have two options:

1. A single branch on return.

2. Multiple return paths.

2a) returning to the calling function

2b) using a landing pad (current solution)

> It won't help with register pressure. Having a pointer to an exception object in a register is equivalent to having a pointer to a TLS memory area in a register.

TLS is in a register already.

>> it can be optimized away so you don't need TLS if you don't span over non-D code.
>>
>
> Without specifics, it is another instance of the sufficiently smart compiler running gag.

This does not take a very smart compiler. You can use heuristics, such as ones using the function signature.

> You don't make things faster by making the calling convention easier. There is chance that this is gonna fly any better than a flat iron.

?

Of course you make it faster by allowing the compiler to use it's own calling conventions.

Just to be clear on this. Sandy Bridge and later have 16 x 256 bits registers. There is really no reason for an optimizing compiler to not just stuff the whole exception value into 1 or 2 of those in most cases where it has full control.

In the rare case where that is not enough, or possible, stuff it into a fixed TLS buffer (or a similar arrangement) and clear a signal value in that buffer when the exception is caught.

That post, to me, only reinforces how much better using exceptions is.

Atila

> They posted recently a blog post about error handling in Go.
>
> https://blog.golang.org/errors-are-values
>
> --
> Paulo

On Tue, 13 Jan 2015 11:56:00 +0000
Paulo  Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> They posted recently a blog post about error handling in Go.
> 
> https://blog.golang.org/errors-are-values
great article! it clearly shows how NOT to do error handling and why exceptions are far superior.