RFC: Change what assert does on error

[Derek Fawcus]

On Friday, 4 July 2025 at 07:16:17 UTC, Adam Wilson wrote:
> On Friday, 4 July 2025 at 06:29:26 UTC, Walter Bright wrote:
>> On 7/3/2025 12:21 AM, Adam Wilson wrote:
>>> It is an absolute non-negotiable business requirement that I 
>>> be able to get debugging information out of the server 
>>> without physical access to the device. If you won't deliver 
>>> the logging data, corrupted or not, on an assert, then no 
>>> business can justify using D in production.
>>
>> I did mention that logging the error before terminating the 
>> process was acceptable. My point is that recovering is not 
>> acceptable.
>
> Kinda hard to do that when the process terminates, especially 
> if the logger is a side-thread of the app like it was on my 
> team at MSFT.
>
> But also, not printing a stack trace means there is nothing to 
> log.

Actually no, as long as the termination is via abort(), then on 
unix type systems the reliable way to get a trace is via an 
external monitor program.

I convinced a colleague of this at a prior large company, and 
offered guidance as he created such a monitor and dump program.  
It was sort of like a specialised version of a debugger, making 
use of the various debugger system facilities.

It was to replace an in process post crash recovery for crash 
dump mechanism.

The actual process being monitored was able to check in with the 
monitor at start up, and provide hints as to where interesting 
pieces of data were based in memory; but once done everything was 
based upon the monitor extracting information, including 
back-tracing the stack(s) from outside the crashed process.