On Friday, 29 January 2021 at 06:03:08 UTC, Andre Pany wrote:
> On Thursday, 28 January 2021 at 17:59:41 UTC, Max Haughton wrote:
>> It has been discussed in a different thread (Making throwing an error an instant failure, catching Error etc.)
>>
>> I am starting to put together a patch to try out this behaviour, what do we actually want it to do - should it call a user specified handler, druntime, c etc.?
>>
>> The rationale makes perfect sense (Errors should indicate something has gone wrong, the program is in an invalid state - by definition you cannot recover), but the exact behaviour must be specified.
>
> What would be the effect of this change on the unit test runners we have (d-unit, silly, unit-threaded)?
> This might break their functionality, as they might catch Errors (unit tests calling assert).
>
> Kind regards
> Andre

It would need to be a flag, I doubt this will ever be the default - however consider that Phobos at least already doesn't throw asserterrors if you test with release - if we wanted it as a option to be widely used it would just be a part of the test suite like any other feature.

On Friday, 29 January 2021 at 00:39:08 UTC, Paul Backus wrote:
> If out-of-bounds array access is defined by the language spec as an unrecoverable error, an optimizing compiler is allowed to assume that no program ever recovers from it, and potentially re-order code based on that assumption. So you cannot actually be sure that "the code following after the random access wouldn't be executed."


Okay, if out-of-bound exceptions cause UB, then we can neither abort the program entirely because UB now belongs to our semantic or the compiler have to completely reject any way of UB at compile time.

I'm a fan of banning any occurrence of UB in a language, rather I prefer things to be implementation defined which is sometimes just not possible because of OS mystery.

On the other side, it isn't anyway possible to assure the implementation satisfies the needs of the frontend, e.g. malloc may not allocate memory at all just print a smiley to console. From this point we could define any operation as UB, but it doesn't make that sense...

On Friday, 29 January 2021 at 14:19:02 UTC, sighoya wrote:
> On Friday, 29 January 2021 at 00:39:08 UTC, Paul Backus wrote:
>> If out-of-bounds array access is defined by the language spec as an unrecoverable error, an optimizing compiler is allowed to assume that no program ever recovers from it, and potentially re-order code based on that assumption. So you cannot actually be sure that "the code following after the random access wouldn't be executed."
>
>
> Okay, if out-of-bound exceptions cause UB, then we can neither abort the program entirely because UB now belongs to our semantic or the compiler have to completely reject any way of UB at compile time.

"Unrecoverable error" does not mean the same thing as UB.

On Thursday, 28 January 2021 at 17:59:41 UTC, Max Haughton wrote:
> It has been discussed in a different thread (Making throwing an error an instant failure, catching Error etc.)
>
> I am starting to put together a patch to try out this behaviour, what do we actually want it to do - should it call a user specified handler, druntime, c etc.?

I think there are two things that need to take into consideration:

* Currently druntime catches all uncaught exceptions, that is `Throwable`, to be able to print the exception message and a stack trace.

* When running unit tests there needs to be safe way to catch whatever `assert` is throwing to be able to continue running other unit tests. druntime relies on this.

--
/Jacob Carlborg

On 29.01.21 07:03, Andre Pany wrote:
> On Thursday, 28 January 2021 at 17:59:41 UTC, Max Haughton wrote:
>> It has been discussed in a different thread (Making throwing an error an instant failure, catching Error etc.)
>>
>> I am starting to put together a patch to try out this behaviour, what do we actually want it to do - should it call a user specified handler, druntime, c etc.?
>>
>> The rationale makes perfect sense (Errors should indicate something has gone wrong, the program is in an invalid state - by definition you cannot recover), but the exact behaviour must be specified.
> 
> What would be the effect of this change on the unit test runners we have (d-unit, silly, unit-threaded)?
> This might break their functionality, as they might catch Errors (unit tests calling assert).

Even the language itself catches AssertError to implement in contract inheritance.

On Friday, 29 January 2021 at 06:03:08 UTC, Andre Pany wrote:
> On Thursday, 28 January 2021 at 17:59:41 UTC, Max Haughton wrote:
>> It has been discussed in a different thread (Making throwing an error an instant failure, catching Error etc.)
>>
>> I am starting to put together a patch to try out this behaviour, what do we actually want it to do - should it call a user specified handler, druntime, c etc.?
>>
>> The rationale makes perfect sense (Errors should indicate something has gone wrong, the program is in an invalid state - by definition you cannot recover), but the exact behaviour must be specified.
>
> What would be the effect of this change on the unit test runners we have (d-unit, silly, unit-threaded)?
> This might break their functionality, as they might catch Errors (unit tests calling assert).
>
> Kind regards
> Andre

Depends on the usage. The reason that unit-threaded catches errors is to support unit tests written with asserts, since those might even have been written before unit-threaded itself was. The idea is to use the custom assertions. My own projects wouldn't be affected in the slightest, for instance.

On 29.01.21 01:39, Paul Backus wrote:
> 
> Of course, the key phrase here is "defined by the language spec." As a language designer, you are free to define out-of-bounds indexing as either recoverable or unrecoverable. But as a programmer, once the decision has been made and the spec has been written, you do not get a choice--either you play by the rules, or your code is wrong.

What you seem to ignore here is that it's the language's job to accommodate the programmer's use cases, not the other way around and that this is a forum where we discuss changes to the language specification.

On 29.01.21 15:23, Paul Backus wrote:
> On Friday, 29 January 2021 at 14:19:02 UTC, sighoya wrote:
>> On Friday, 29 January 2021 at 00:39:08 UTC, Paul Backus wrote:
>>> If out-of-bounds array access is defined by the language spec as an unrecoverable error, an optimizing compiler is allowed to assume that no program ever recovers from it, and potentially re-order code based on that assumption. So you cannot actually be sure that "the code following after the random access wouldn't be executed."
>>
>>
>> Okay, if out-of-bound exceptions cause UB, then we can neither abort the program entirely because UB now belongs to our semantic or the compiler have to completely reject any way of UB at compile time.
> 
> "Unrecoverable error" does not mean the same thing as UB.

Why is that an useful thing to mandate on the language level? I can always choose to terminate the process if I actually think nothing useful remains to be done after hitting some condition. Even if the error is not recoverable, I might have something to say about how I want the program to not recover.

The problem that needs to be solved is that you can catch errors and errors can be thrown from nothrow functions, and Walter does not want to allow exceptional control flow out of nothrow functions, as that defeats one of the reasons why that feature exists in the first place.