Why is it so difficult to get a core dump for exceptions/errors?

[Marenz]

One thing that bugged me for years in D is how difficult it is to 
get a useful core dump.

A very common situation is that one of your calls fails, throws 
an exception you haven't
anticipated.

The intuitive thing (and the thing that basically all other 
languages do) is to do
whatever the equivalent of `abort()` or `kill -ABRT` is: Do a 
core-dump exit.
An exit of this kind can be caught in the debugger or creates a 
core file which
can be read in the debugger.

I have all state information for every frame, I can investigate 
in detail what's going
on and wrong.

I know there is the `rt_trapExceptions` variable which can be set 
if you go the
complicated way of writing your own main entry function.

But even that doesn't help if the same thing happens to you in a 
Fiber.

My current situation is for example this:

My server application sometimes crashes, the stdout log only 
saying

```
Task terminated with unhandled exception: Invalid memory operation
Full error: 
core.exception.InvalidMemoryOperationError at src/core/exception.d(693): Invalid memory operation
----------------
uncaught exception
dwarfeh(224) fatal error
```

helpfulness: zero. And I already employed the rt_trapExceptions 
trick here.
What I have to do to get a meaningful core dump and thus stack 
trace here is to actually change core/thread.d and make it call 
fibers without the `try/catch` combination.

I think this is pretty terrible in terms of developer-usability 
and it makes it unnecessarily difficult.




Further more, why is it even catching `Error`s? I thought errors 
should never be caught. If it would just catch exceptions that 
would.. still be annoying but at least more acceptable. And the 
rt_trapException switch would then makes it not even catch 
exceptions.

That's what would make sense to me. What I'd consider intuitive 
would be to do no catching at all of course. Or at the very least 
have an easy way to disable it. For fibers AND for main().