- 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
Edit 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.
Edit 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.
Edit Admin
Wouldn't that be just forget without fire?
Edit 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.
Edit 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
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.