- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
C++ takes a frist step further on the harshness scale, in that all unhandled exceptions call
std::terminatewhich does to your program what its name suggests, bye-bye, but with the advantage that it happens immediately rather than when the GC decides to run some time later.OK, admittedly that's partly because there is no GC, but ...
Admin
And they didn't have the good sense to log the reason of the crash? As in: "exception ... was raised, and you didn't even look at it, you dummy!" Well, it wouldn't be the frist time.
Admin
The Garbage Collector decided that the program was clearly garbage, and collected it. Seems right to me.
Admin
Perhaps I'm not understanding....but if the tasks are just fire-and-forget and failure is acceptable, then just comment out the "seeder.RunSeeder()" line and be done.
Admin
Wouldn't that be just forget without fire?
Admin
Tasks are code using an execution and synchronization context enqueued into the thread pool. You can only fire-and-forget Tasks when both contexts support it and never in an asynchronous context.
Fire&Forget in software development is generally a very, very bad idea. That's how you produce race conditions and deadlocks and those fun errors that make maintaining and debugging code impossible. And ironically it's a clear code smell because it's often because someone was sloppy, the architecture is messed up or someone simply had no idea what they are doing. For those rare instances where you actually need it (emphasis on need vs want) there are often high-level APIs available in underlying frameworks providing the synchronization context to do so.
Admin
If failure is acceptable, the tasks didn't seem to do anything important anyway :D
Admin
In my experience, if code is raising an exception you don't care about, then the question usually needs to be asked as to why the code is throwing an exception...
Admin
I disagree with you and Microsoft, simply because the garbage collector should be totally transparent. Every garbage collector should be equivalent to running your code on a machine with infinite resources and no garbage collector; the only purpose of the garbage collector is to free any resources it knows aren't being used. Anything extra, especially anything that can cause random crashes, is heresy.
To be clear, I realize that other people who write garbage collectors disagree with this take. But they're wrong and I'm right.
Admin
Error handling of background jobs is always a pain in the ass. Interactive stuff, there's always somewhere for an exception to propagate up to, but when something has been fired off on another thread where nobody is watching it, you have to deal with it yourself.
Admin
Pedantically, I wasn't saying that the garbage collector should do it, but that an unhandled exception in a task should fail dramatically. Now, it makes more sense for your task runner to be responsible; it's equally as opaque to the caller, but a more logical place for it to happen.
Admin
There should be a default exception handler that logs otherwise-unhandled exceptions when they propagate out of a task. (Maybe it should also terminate the program, maybe not. Depends on the application.) That's a good thing, and many language runtimes have this concept.
Having the garbage collector crash because of an unhandled user exception is very WTF to the point of being downright demented. I didn't know that any version of C# (or anything else using the .NET runtime) was that awful. Obviously there's an abundance of mushrooms up in rainy Redmond, because delivering a process-crashing exception into the system at what's essentially a random time is just idiotic. GC should just throw away the garbage, not become part of the garbage itself.