Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....

[John Carter]

On Wednesday, 11 July 2018 at 12:45:40 UTC, crimaniak wrote:
> The error should be maximally localized, and the programmer 
> should be able to respond to any type of errors. The very 
> nature of the work of WEB applications contributes to this. As 
> a rule, queries are handled by short-lived tasks that work with 
> thread-local memory, and killing only the task that caused the 
> error, with the transfer of the exception to the calling task, 
> would radically improve the situation.

Hmm. The fun fun fun thing about undefined behaviour in the 
absence of MMU's is the effects are maximally _unlocalized_.

ie. It can corrupt _any_ part of the system.

A use after free for example, or an index out of bounds on the 
heap, can corrupt all and any  subsystem sharing the same virtual 
address space.

Part of the reason why Walter is pushing so hard for memory 
safety.

Memory Safety is truly a huge step away from the world of pain 
that is C/C++.... it removes a truly huge class of defects.

However, it also removes a common terminology. Odds on you know 
what I mean when I say "use after free" or "index out of bounds".

Now in the levels above the language and the library, humans are 
equally capable of screwing up and corrupting our own work.... 
except the language can no longer help you.

Above the language and the library, we no longer have a common 
terminology for describing the myriad ways you can shoot yourself 
in the foot.

The language can, through encapsulation "minimize the blast 
radius", but can't stop you.

I disagree with Bjarne Stroustrup on many things.... but in this 
article he is absolutely spot on. 
https://www.artima.com/intv/goldilocks3.html

Please read it, it's probably the most important article on 
Object Oriented Design you'll find.

Now the problem with "unexpected" exceptions is, odds on you are 
left with a broken invariant.

ie. Odds on you are left with an object you now cannot reasonably 
expect to function.

ie. Odds on that object you cannot expect to function, is part of 
a larger object or subsystem you now cannot reasonably expect to 
function.

ie. You left with a system that will progressively become flakier 
and flakier and less responsive and less reliable.

The only sane response really is to reset to a defined state as 
quickly as possible. ie. Capture a backtrace, exit process and 
restart.

Your effort in trying to catch and handle unexpected events to 
achieve uptime is misplaced, you are much better served by Chaos 
Monkeys.

ie. Deliberately randomly "hard kill" your running systems at 
random moments and spend your efforts on designing for no 
resulting corruption and rapid and reliable reset.

I certainly wouldn't unleash Chaos Monkeys on a production system 
until I was really comfortable with the behaviour of on a test 
system....