On 02/07/2025 7:18 AM, Kagamin wrote:
> On Sunday, 29 June 2025 at 20:58:36 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> 4. assert is a framework level error mechanism, not "this process can't continue if its false". We'll need something else for the latter, it can be library code however.
> 
> ```
> landmine(a.length!=0);
> ```
> Not sure how long should be the name.

I was thinking suicide, but.. that is certainly a less trigger warning requiring name.

On Tuesday, 1 July 2025 at 21:19:31 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 02/07/2025 7:18 AM, Kagamin wrote:
>> On Sunday, 29 June 2025 at 20:58:36 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> 4. assert is a framework level error mechanism, not "this process can't continue if its false". We'll need something else for the latter, it can be library code however.
>> 
>> ```
>> landmine(a.length!=0);
>> ```
>> Not sure how long should be the name.
>
> I was thinking suicide, but.. that is certainly a less trigger warning requiring name.

Why not a more insensitive one `pungeepit`?

On Tue, Jul 01, 2025 at 07:18:42PM +0000, Kagamin via Digitalmars-d wrote:
> On Sunday, 29 June 2025 at 20:58:36 UTC, Richard (Rikki) Andrew Cattermole
> wrote:
> > 4. assert is a framework level error mechanism, not "this process can't continue if its false". We'll need something else for the latter, it can be library code however.
> 
> ```
> landmine(a.length!=0);
> ```
> Not sure how long should be the name.

Just learn from Perl:

	# Perl
	die if ($a != 0);

	# Proposed D
	die(a.length != 0);

;-)


T

-- 
I tried to make a belt out of herbs, but it was just a waist of thyme.

Currently, the behavior of an assert error can be set with the command line:

Behavior on assert/boundscheck/finalswitch failure:
  =[h|help|?]    List information on all available choices
  =D             Usual D behavior of throwing an AssertError
  =C             Call the C runtime library assert failure function
  =halt          Halt the program execution (very lightweight)
  =context       Use D assert with context information (when available)

Note that the =D behavior really means calling the onAssertError() function in core.exception:

https://dlang.org/phobos/core_exception.html#.onAssertError

which can will call (*_assertHAndler)() if that has been set by calling assertHandler(), otherwise it will throw AssertError. _assertHandler is a global symbol, not thread-local.

https://dlang.org/phobos/core_exception.html#.assertHandler

I know, this is over-engineered and poorly documented, but it is very flexible.

On 6/30/2025 2:18 PM, Sebastiaan Koppe wrote:
> Just know that the idea of exiting directly when something asserts on the pretense that continueing makes things worse breaks down in multi-threaded programs.

An assert tripping means that you've got a bug in the program, and the program has entered an unanticipated, unknown state. Anything can happen in an unknown state, for instance, installing malware. As the threads all share the same memory space, doing something other than aborting the process is highly unsafe.

Depending on one's tolerance for risk, it might favor the user with a message about what went wrong before aborting (like a backtrace).

But continuing to run other threads as if nothing happened is, bluntly, just wrong. There's no such thing as a fault tolerant computer program.

D is flexible enough to allow the programmer to do whatever he wants with an assert failure, but I strongly recommend against attempting to continue as if everything was normal.

BTW, when I worked at Boeing on flight controls, the approved behavior of any electronic device was when it self-detected a fault, it immediately activated a dedicated circuit that electrically isolated the failed device, and engaged the backup system. It's the only way to fly.

On Wednesday, 2 July 2025 at 08:11:44 UTC, Walter Bright wrote:
> Anything can happen in an unknown state, for instance, installing malware. As the threads all share the same memory space, doing something other than aborting the process is highly unsafe.

Since they share access to the same file system, doing anything other than igniting the thermite package in the hard drive is liable to lead to compromise by that installed malware. And if that computer was connected to a network... God help us all, we're obligated to press *that* button.

You can never be too safe!

* * *

I keep hearing that asserts and Errors and whatnot only happen when the program has encountered a bug, but it is worth nothing they tend to happen *just before* a task actually executes the problematic condition. Sure, you weren't supposed to even get to this point, but you can still reason about the likely extent of the mystery and rollback to that point... which is what stack unwinding achieves.

Yeah, there's some situations were all is in fact lost and you wanna call abort(). Well, you can `import core.stdc.stdlib` and call `abort()`! But normally, you can just not catch the exception.

This is why OpenD tries to make sure that stack unwinding actually works - it will call destructors as it goes up, since this is part of rolling back unfinished business and limiting the damage. It throws an error prior to null pointer dereferences. It gives you a chance log that information since this lets you analyze the problem and correct it in a future version of the program. Yes, you could (and probably should) use a JIT debugger too, operating systems let you gather all this in a snapshot.... but sometimes user deployments don't let you do that. (those ridiculously minimal containers everybody loves nowadays, my nemesis!!!) Gotta meet users where they actually are.

Our story on the threads missing information remains incomplete, however. I have some library support in the works but it needs integration in the druntime to be really universal and that isn't there yet. Soon though!

On Wednesday, 2 July 2025 at 08:11:44 UTC, Walter Bright wrote:
> On 6/30/2025 2:18 PM, Sebastiaan Koppe wrote:
>> Just know that the idea of exiting directly when something asserts on the pretense that continueing makes things worse breaks down in multi-threaded programs.
>
> An assert tripping means that you've got a bug in the program, and the program has entered an unanticipated, unknown state. Anything can happen in an unknown state, for instance, installing malware. As the threads all share the same memory space, doing something other than aborting the process is highly unsafe.
>
> Depending on one's tolerance for risk, it might favor the user with a message about what went wrong before aborting (like a backtrace).
>
> But continuing to run other threads as if nothing happened is, bluntly, just wrong. There's no such thing as a fault tolerant computer program.

I absolutely understand your stance. There are programs where I would blindly follow your advice. It's just that there 99x as many where graceful shutdown is better.

Also, most triggered asserts I have seen were because of programmer bugs, as in, they misused some library for example, not because of actual corruption or violation of some basic axiom.

> D is flexible enough to allow the programmer to do whatever he wants with an assert failure, but I strongly recommend against attempting to continue as if everything was normal.

Exactly. People who design highly critical systems can be assumed to know how to flip the default handler.

> BTW, when I worked at Boeing on flight controls, the approved behavior of any electronic device was when it self-detected a fault, it immediately activated a dedicated circuit that electrically isolated the failed device, and engaged the backup system. It's the only way to fly.

Good for Boeing, not for my apps.

Having said that, I do see some parallel with large-scale setups where backend servers often employ health checks to signal they are ok to receive requests.

Similarly, during deployment of new software people often use error rates as an indication whether to continue rollout or back out instead.

There is wisdom in all that, I don't deny that. But again, people in that position are smart enough to configure the runtime to abort at first sight, if that is what they want. For my little cli app I rather want graceful shutdown instead.

On Tuesday, 1 July 2025 at 21:39:04 UTC, H. S. Teoh wrote:
> On Tue, Jul 01, 2025 at 07:18:42PM +0000, Kagamin via Digitalmars-d wrote:
>> On Sunday, 29 June 2025 at 20:58:36 UTC, Richard (Rikki) Andrew Cattermole
>> wrote:
>> > 4. assert is a framework level error mechanism, not "this process can't continue if its false". We'll need something else for the latter, it can be library code however.
>> 
>> ```
>> landmine(a.length!=0);
>> ```
>> Not sure how long should be the name.
>
> Just learn from Perl:
>
> 	# Perl
> 	die if ($a != 0);
>
> 	# Proposed D
> 	die(a.length != 0);

That is actually how you throw an exception in Perl. Catch it with
eval and examine the thrown object in $@:

   eval {
       die "something interesting happend"; # "throw"
   };
   if ($@) {                                # "catch"
       warn "caught $@\n";
   }

You may even instruct the runtime to generate a stack dump:

   use Carp;
   $SIG{__DIE__} = 'confess';

Since Perl is refcounted there is no weird magically confused runtime
after an exception has been thrown.