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@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().
