Assertions getting corrupted

[bauss]

On Thursday, 26 October 2017 at 06:27:53 UTC, Jonathan M Davis 
wrote:
> On Thursday, October 26, 2017 09:04:56 Shachar Shemesh via 
> Digitalmars-d wrote:
>> ...
>
> Walter believes that it's worse to do cleanup when an Error is 
> thrown than it is to not do cleanup, because the program is an 
> unknown and invalid state, and the cleanup code could do more 
> harm than good. Others have argued that it's better to run as 
> much cleanup code as possible and that it's worse to skip 
> cleanup, since usually, the program will be in a valid enough 
> state that the cleanup will work and other problems will be 
> avoided by doing that cleanup.
>
> - Jonathan M Davis

For web-development your program may not be an invalid state even 
if an error is thrown, a user may be in an invalid state, but you 
don't want your whole website to go down, because one user got 
into an invalid state.

Example on an error thrown where the program is still in a valid 
state.

void doStuffOnUser(User user)
{
     if (!user.role.permissions) return;

     // ...
}

Let's say role gets set from the session of the user, which means 
it's tied to user's browser, so if the session fails to be 
retrieved and the code still continues to this function then role 
would be null.

Of course it's a bug in the program and you __could__ argue that 
the program is in an invalid state, but for web applications you 
don't want it to crash over bugs, you just want it to log and 
then hopefully no more runs into that issue so you can fix it 
asap.You want to guarantee up-times no matter what.

But anyway since role is null we'll get an access violation, 
which is not an exception. However the state is only invalid for 
that one user and possibly not every other user you have, but 
because it's not an exception the whole program will crash if you 
actually follow the D guide-lines for exceptions, which 
couldcause down-time for thousands of users if you have a big 
website.

If it happens in the night-time the website could be down for 
hours, before you even know about it and that is __really__ bad, 
because depending on the website it could be a lot money that 
you're losing.

Time is money, especially when it comes to web applications.

Amazon did a test once by making their load times 100ms slower 
and they lost millions in revenue, so imagine if they had hour 
long down times. It most likely would be catastrophic.

If D really wants to succeed with such things, then we cannot 
assume the program is in an invalid state. It must be up to the 
developer themselves to figure out if it's in an invalid state or 
not.