On Monday, 6 January 2020 at 06:58:34 UTC, Paul Backus wrote:
> On Monday, 6 January 2020 at 03:13:09 UTC, Guillaume Piolat wrote:
>> On Saturday, 4 January 2020 at 16:05:10 UTC, Steven Schveighoffer wrote:
>>> Just wanted to bring this up, and not muddy the other thread.
>>>
>>> What do you put if you throw? @safe by default has alternatives. nothrow does not. Are we going to get a new keyword/uda?
>>>
>>> -Steve
>>
>> WHY would nothrow by the default in the first place?
>>
>> Exceptions are about the best error handling mechanism and there is no better altnernative in D.
>
> `nothrow` by default doesn't stop you from using exceptions, it just forces you to either catch them or mark your function as throwing.

What do you think people will do:
A - handle the exception correctly at the right place and mark the whole chain of calls as `throws`
B - mark a single function as `nothrow` and catch the Exception with a dummy handler

B is dangerously easier to do.

Also the statu quo isn't so bad: an unhandled exception crash, which is an unrecoverable error, as good as an assertion-in-release. Not handling one is a bug, and it acts like so.

How many times will D break all code in the future?

On Saturday, 4 January 2020 at 21:07:03 UTC, Adam D. Ruppe wrote:
> pure!false
> @nogc!true
> nothrow!default
> virtual!false

nopure / novirtual / no...

I always wanted to get # for language attributes and @ for uda

#safe #nothrow #nopure
@myuda
void blah()
{
}

I'm aware that C++ is moving away from exceptions. I've been unhappy with exceptions for some time now (DMD doesn't use them for performance reasons), and C++ has evidently come to the same conclusion.

I expect that exceptions will soon become a legacy feature.

On 1/5/2020 4:27 AM, Gregor Mückl wrote:
> It would be nice to have choice here.
> 
>> 2) (Optional): Herb arguest that because of throw ... it is easy to spot
>>    where an exception originates, but it's more difficult to find where
>>    an exception was propagated. As a solution,
>>    whenever calling a throws function, the calls should be preceeded by
>>    throw:
>>    auto value = throw myThrowingFunction();
>>    Here throw does essentially this: If myThrowingFunction threw, rethrow
>>    the exception. Otherwise return the return value.
>>
> 
> I hope that this doesn't require code to have a throw keyword in every other line.

For D, the `throw` attribute will apply to the function, not the statement.

On Wednesday, January 8, 2020 11:26:41 PM MST Walter Bright via Digitalmars- d wrote:
> I'm aware that C++ is moving away from exceptions. I've been unhappy with exceptions for some time now (DMD doesn't use them for performance reasons), and C++ has evidently come to the same conclusion.
>
> I expect that exceptions will soon become a legacy feature.

I would really hope not. IMHO, they are usually by far the best way to handle error conditions in a program. Anything else results in you having to deal with the various possible error conditions when the function returns, which is _far_ more unwieldy and much more error-prone. It also doesn't work well with function call chaining.

By using exceptions, you eliminate the need to have error-handling code everywhere in your program, and unlike stuff like error codes, exceptions don't get eaten unless the programmer specifically puts in effort to make it happen.

I wouldn't mind us getting rid of Error in favor of killing the program on the spot, since that's actually better for debugging, and it avoids the whole argument about whether it's okay to catch Errors. However, Exceptions are for runtime conditions that aren't necessarily a bug, and they can often be recovered from. So, being able to throw Exceptions is extremely useful, and the fact that they don't force you to check for error conditions everyewhere and instead just handle them in the spots where it makes sense to handle them makes the code _way_ cleaner.

IMHO, having nothrow be the default would be terrible, and trying to treat exceptions as a legacy feature would be even worse.

- Jonathan M Davis

On Thursday, 9 January 2020 at 10:32:25 UTC, Jonathan M Davis wrote:
> On Wednesday, January 8, 2020 11:26:41 PM MST Walter Bright via Digitalmars- d wrote:
>> [...]
>
> I would really hope not. IMHO, they are usually by far the best way to handle error conditions in a program. Anything else results in you having to deal with the various possible error conditions when the function returns, which is _far_ more unwieldy and much more error-prone. It also doesn't work well with function call chaining.
>
> [...]

I absolutely agree with all your points. From a compiler developer view, Walter is right. But from an application developer view, reducing the usability of Exceptions is terrible bad.

Kind regards
Andre

On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:
> I expect that exceptions will soon become a legacy feature.

I've seen no evidence of that whatsoever. Exceptions, like GC, are a proven winner in the real world with the vast majority of actually existing industry code using them successfully.

Reminder that exceptions were invented because error codes *cannot* say the same thing.

There are some new techniques being tried out in some places to varying levels of success. Those features are useful for other purposes too, so I wouldn't mind D picking some of them up, like I said in a previous message.

But even with those available, I expect that error handling mode will remain relatively niche because of the enormous success exceptions have and have had proven in industry.

On Thursday, 9 January 2020 at 10:32:25 UTC, Jonathan M Davis wrote:
>
> I wouldn't mind us getting rid of Error in favor of killing the program on the spot, since that's actually better for debugging, and it avoids the whole argument about whether it's okay to catch Errors.

Yes please!

> However, Exceptions are for runtime conditions that aren't necessarily a bug, and they can often be recovered from. So, being able to throw Exceptions is extremely useful, and the fact that they don't force you to check for error conditions everyewhere and instead just handle them in the spots where it makes sense to handle them makes the code _way_ cleaner.
>
> IMHO, having nothrow be the default would be terrible, and trying to treat exceptions as a legacy feature would be even worse.
>
> - Jonathan M Davis

+1, and I would add that when writing modern C++11 with only linear types, exceptions + RAII quickly appear as the _only way_ to have correct desctruction teardown in error conditions (the least tested pathes).
Anything else is just bring undetected errors in error paths, like in C. GC only catches non-reclaimed memory...

On Thursday, 9 January 2020 at 10:32:25 UTC, Jonathan M Davis wrote:
> On Wednesday, January 8, 2020 11:26:41 PM MST Walter Bright via Digitalmars- d wrote:
>> I'm aware that C++ is moving away from exceptions. I've been unhappy with exceptions for some time now (DMD doesn't use them for performance reasons), and C++ has evidently come to the same conclusion.
>>
>> I expect that exceptions will soon become a legacy feature.
>
> I would really hope not. IMHO, they are usually by far the best way to handle error conditions in a program. Anything else results in you having to deal with the various possible error conditions when the function returns, which is _far_ more unwieldy and much more error-prone. It also doesn't work well with function call chaining.

I doubt Stroustrup will let that happen. Highly unlikely scenario.

Not sure why anyone would think that exceptions are gone just because some want to enable compilers configured to compile without exceptions to use more library containers (like std::vector)?

 C++17 certainly introduced new exceptions (std::filesystem::filesystem_error), and I believe more C++ setups enable exceptions today than a decade ago. For good reasons.

No need to avoid exceptions in the whole program just because you don't want them in som specific locations (like render code).

Whole program analysis and inter-procedural analysis should be able to take care of it.

On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:
> I'm aware that C++ is moving away from exceptions. I've been unhappy with exceptions for some time now (DMD doesn't use them for performance reasons), and C++ has evidently come to the same conclusion.
>
> I expect that exceptions will soon become a legacy feature.

Value type exceptions as proposed by Herb and others are still exceptions.

Error codes are just to keep the "exceptions only over by dead body" crowd happy, and to try to move them away from non-compliant C++ with exceptions and RTTI turned off.

C++/WinRT turns COM error codes into C++ exceptions, Android NDK has C++ exceptions enabled by default.