On Sat, 1 Jul 2017 14:14:06 +0200, Sönke Ludwig wrote:

Am 30.06.2017 um 17:49 schrieb Alexey Kulentsov:

On Wed, 31 May 2017 08:44:55 -0400, Steven Schveighoffer wrote:

Thinking some more about it, we can't really make them exceptions,
because then nothrow code becomes nearly impossible to write, or as
painful as writing Java code.
This is one of the reasons why I will never try to do any commercial web jobs with D again. We so badly want to write nothrow code (WHY??), so let's make the language completely inappropriate for web programming! In fact, the current std library implementation destroyed the declared difference between the Error and the Exception. The standard library just overfilled by asserts(), so it needs a lot of work to make it more or less tolerant to really recoverable errors. I don't think it will happen. :(

I agree that this is can be very painful at times. Personally, I can
tolerate range errors and assertions, but the ones that are just an
artifact of the particular GC implementation (OutOfMemoryError and
`InvalidMemoryOperationErrors') really bother me.

It seems that my point of view is more extreme in this sense. Any living commercial project is constantly subject to modifications. A certain number of errors, despite testing, inevitably seeps into production. Any such error detected by the attacker, with the current response policy (completely dropping the application) becomes the possibility of a very easy DOS attack. Therefore, for web programming, it is simply necessary that errors be interceptable.

But I think it would be sensible to add a compiler option to make
catching Error always safe on a low level (i.e. to always insert stack
cleanup code, even in nothrow functions). It would be a performance
trade-off that everyone can decide on on their own. Of course, this
would still leave GC errors as unsafe, because the implementation lacks
the proper cleanup logic.

For everything else it would be correct to just drop the current fiber
and to assume that other fibers (or threads) are unaffected, as long as
no shared data is affected.

Yes, the proposed methods can help, this is a fairly global approach. But is there any chance that this will be implemented?