On Wednesday, 14 January 2015 at 10:37:31 UTC, Atila Neves wrote:
> 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

Agree, on the other hand is another example of the mindset.

--
Paulo

On Tuesday, 13 January 2015 at 20:58:43 UTC, deadalnix wrote:
> On Tuesday, 13 January 2015 at 19:36:31 UTC, Marc Schütz wrote:
>> On Monday, 12 January 2015 at 23:01:53 UTC, Ola Fosheim Grøstad wrote:
>>> On Monday, 12 January 2015 at 22:06:32 UTC, deadalnix wrote:
>>>> No, Exception are a bail out mechanism. It is the, I have no idea what to do about this mechanism.
>>>
>>> The way it is done in C++, yes.
>>>
>>>> If you put aside performance concerns, exceptions for control flow also tend to make many code path implicit and makes for very unreadable/unmaintainable code.
>>>
>>> But exceptions are control flow. There is no such thing as normalized control flow, all state changes implies "control flow". Think in terms of a state machine. You could just remove all variables and only have a big state machine (assuming finite dimensions). Every single state transition implies flow of control.
>>>
>>> The control flow you see in the source code is just the programmer's "rendition" of control flow. Exceptions is a mechanism for getting cluttering resolution out of that rendition to make the code more readable and maintainable. The goal is to retain the meat of the computation and remove the noise.
>>>
>>> Or to put it differently, there are many ways to write the same function. Good use of exceptions removes the clutter and leaves the things you care about visible. It's a mechanism, not a moral issue or a religion.
>>>
>>> So there is nothing wrong with throwing HTTPStatus(409) or HTTPStatus(201), even though it returns state to the environment. If that means the code is more maintainable and more likely to be correct, then that is good use of the mechanism.
>>
>> I usually don't do this, but I really need to post a "+1" here:
>>
>> +1
>
> Too bad you chose to do this on a bad strawmman.

Your claims:

- Exceptions are for "I have no idea what to do about this" situations.
- "exceptions for control flow [...] makes for very unreadable/unmaintainable code"

Ola's answer directly addresses these claims and provides a counter-example (in the last paragraph), which I happen to agree with.

=> Not a strawman.

On Wednesday, 14 January 2015 at 00:24:41 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 13 January 2015 at 23:58:53 UTC, deadalnix wrote:
>>
>> http://dlang.org/phobos/core_thread.html#.Thread.join
>
> I don't see the problem. I'm suggesting value semantics, it can be copied.

Without addressing anything else: You want moving here, not copying.

On Wednesday, 14 January 2015 at 11:20:49 UTC, Marc Schütz wrote:
> Without addressing anything else: You want moving here, not copying.

How can you move a value, it has no identity?

(Not that I really care much for Thread.join(). How many actually use it?)

On Wednesday, 14 January 2015 at 11:17:52 UTC, Marc Schütz wrote:
> Your claims:
>
> - Exceptions are for "I have no idea what to do about this" situations.
> - "exceptions for control flow [...] makes for very unreadable/unmaintainable code"
>
> Ola's answer directly addresses these claims and provides a counter-example (in the last paragraph), which I happen to agree with.
>
> => Not a strawman.

Being precise is important.

The example presented (ie throwing a exception signaling a http code) is a good one and never contradict what I said.

It is an example "I have no idea what to do about this". The code throwing the exception is faced with a situation where it cannot continue (assuming this code is expected to generate a webpage or something like that) but at the same time, is not in a position to perform the custom http so it is bailing out. It is signaling to higher level "I would have liked to return this http code, but have no idea how to do so and so I'm giving up."

Now I see how you can consider this as a control flow, but it is vastly different from usual control flow (loops, branches, calls, ...). It is vastly different. You have no idea where you send your program into. In fact, you may not even be in in the framework that can make sens of this exception, you have no idea. Conversely, the framwork that is catching this exception have no idea where it came from, and it do not care either. It simply know that the page failed to render and that instead it should return a specific error code.

On Wednesday, 14 January 2015 at 07:49:09 UTC, Ola Fosheim Grøstad wrote:
>> 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.
>

Once again, no specifics.

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

I was not lost. I know how to recognize a non sequitur when I read one.

>> 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's a good thing that you can do all of these in D already.

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

You only need this when you are using static TLS variable, which is not that common in practice. The change would makes this required all over the place.

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

It is a known fact that a sufficiently smart compiler will use heuristic. It is also fairly obvious that this heuristic will use 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.

Making a new calling convention is not going to magically make things faster. If the calling convention need to do more, it is certainly going to make things slower.

Hopefully, function calls are not common at all, so that shouldn't be a problem.

On Wednesday, 14 January 2015 at 17:45:28 UTC, deadalnix wrote:
> It is an example "I have no idea what to do about this". The code throwing the exception is faced with a situation where it cannot continue (assuming this code is expected to generate a webpage or something like that) but at the same time, is not in a position to perform the custom http so it is bailing out.

No, "201" means success, resource created, and "409" means that it was not carried out because of conflict in the request. However, these may be meaningful responses to the client based on the input, like "204" no content. So it is output.

Throwing an exception is just an efficient way to abort all resources and queries that may be in progress and return a status to the client in a clean fashion when you don't need a text body. Just a mechanism. And it makes sense if used consistently.

On Wednesday, 14 January 2015 at 17:53:54 UTC, deadalnix wrote:
> Once again, no specifics.

How is a bitmask (e.g. a set) not specific?

> I was not lost. I know how to recognize a non sequitur when I read one.

Then you should also be able to explain where you got lost.

>> 1. A single branch on return.
>>
>> 2. Multiple return paths.
>>
>> 2a) returning to the calling function
>>
>> 2b) using a landing pad (current solution)
>>
>
> It's a good thing that you can do all of these in D already.

This is about what the compiler does, not what you can do in D. So no. You cannot have multiple return paths (like returning to the returnaddress+OFFSET) or branch implicitly based on the carry flag upon return.

> You only need this when you are using static TLS variable, which is not that common in practice. The change would makes this required all over the place.

That's the point. To have a buffer in TLS so that you don have to do transient heap allocations (allocation directly followed by deallocation of same object).

> Making a new calling convention is not going to magically make things faster. If the calling convention need to do more, it is certainly going to make things slower.

One needs a calling convention to ensure that the backend puts the exception signal in the right register or to do offset return. Or to free up more registers. Haskell has a register heavy calling convention to speed up Haskell code.

So it is not certainly going to make things slower. Clearing a flag/register will most likely fill in a bubble in the pipeline. A predicted non-branching branch instruction is fairly cheap.

> Hopefully, function calls are not common at all, so that shouldn't be a problem.

?

On Tue, Jan 13, 2015 at 8:26 PM, deadalnix via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

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


You are completely right.  Let me rephrase:

The article gives a good overview of the places where checked exceptions are weak, and where people have problems with them.  The things it mentions have best-practice work arounds (or are actually features), and do not invalidate all the usefulness that checked exceptions provide.

It would be great if there were some other scheme instead of checked exceptions, or a slightly different design of them, if it gave me the same advantages without the issues.  Unfortunately I have not seen one yet.

On Wed, Jan 14, 2015 at 3:16 AM, Paulo Pinto via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Wednesday, 14 January 2015 at 10:37:31 UTC, Atila Neves wrote:
>
>> 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
>>>
>>
> Agree, on the other hand is another example of the mindset.
>

It is interesting to me that as people come up with ways to make error-code handling better it starts looking very much like exceptions.