Computer
Ferrari Aims at AI Generation With Crypto Auction For Le Mans Car
Read more of this story at Slashdot.
IBM To Cut Thousands of Roles in Focus on Software Growth
Read more of this story at Slashdot.
Ex-Cybersecurity Staff Charged With Moonlighting as Hackers
Read more of this story at Slashdot.
Amazon Accuses Perplexity of Computer Fraud, Demands It Stop AI Agent From Buying On Its Site
Read more of this story at Slashdot.
Apple Prepares To Enter Low-Cost Laptop Market for First Time
Read more of this story at Slashdot.
Australia Introduces 'Landmark' Streaming Content Quotas
Read more of this story at Slashdot.
Meet the Real Screen Addicts: the Elderly
Read more of this story at Slashdot.
ISPs More Likely To Throttle Netizens Who Connect Through Carrier-Grade NAT: Cloudflare
Read more of this story at Slashdot.
Amazon Builds First Solo Subsea Cable Linking Maryland To Ireland
Read more of this story at Slashdot.
Dick Cheney, Powerful Former VP, Dies at 84
Read more of this story at Slashdot.
What Happened When Small-Town America Became Data-Center, USA
Read more of this story at Slashdot.
DOJ Accuses US Ransomware Negotiators of Launching Their Own Ransomware Attacks
Read more of this story at Slashdot.
EV Sales Plummet In October After Federal Tax Credit Ends
Read more of this story at Slashdot.
Australians To Get At Least Three Hours a Day of Free Solar Power - Even If They Don't Have Solar Panels
Read more of this story at Slashdot.
Undefined Tasks
Years ago, Brian had a problem: their C# application would crash sometimes. What was difficult to understand was why it was crashing, because it wouldn't crash in response to a user action, or really, any easily observable action.
The basic flow was that the users used a desktop application. Many operations that the users wanted to perform were time consuming, so the application spun up background tasks to do them, thus allowing the user to do other things within the application. And sometimes, the application would just crash, both when the user hadn't done anything, and when all background jobs should have been completed.
The way the background task was launched was this:
seeder.RunSeeder();It didn't take too much head scratching to realize what was running every time the application crashed: the garbage collector.
RunSeeder returned a Task object, but since Brian's application treated the task as "fire and forget", they didn't worry about the value itself. But C# did- the garbage collector had to clean up that memory.
And this was running under .Net 4.0. This particular version of the .Net framework was a special, quantum realm, at least when it came to tasks. You see, if a Task raises an exception, nothing happens. At least, not right away. No one is notified of the exception unless they inspect the Task object directly. There's a cat in the box, and no one knows the state of the cat unless they open the box.
The application wasn't checking the Task result. The cat remained in a superposition of "exception" and "no exception". But the garbage collector looked at the task. And, in .Net 4.0, Microsoft made a choice about what to do there: when they opened the box and saw an exception (instead of a cat), they chose to crash.
Microsoft's logic here wasn't entirely bad; an uncaught exception means something has gone wrong and hasn't been handled. There's no way to be certain the application is in a safe state to continue. Treating it akin to undefined behavior and letting the application crash was a pretty sane choice.
The fix for Brian's team was simple: observe the exception, and choose not to do anything with it. They truly didn't care- these tasks were fire-and-forget, and failure was acceptable.
seeder.RunSeeder().ContinueWith(t => { var e = t.IsFaulted ? t.Exception : null; }); // Observe exceptions to prevent quantum crashesThis code merely opens the box and sees if there's an exception in there. It does nothing with it.
Now, I'd say as a matter of programming practice, Microsoft was right here. Ignoring exceptions blindly is a definite code smell, even for a fire-and-forget task. Writing the tasks in such a way as they catch and handle any exceptions that bubble up is better, as is checking the results.
But I, and Microsoft, were clearly on the outside in this argument. Starting with .Net 4.5 and moving forward, uncaught exceptions in background tasks were no longer considered show-stoppers. Whether there was a cat or an exception in the box, when the garbage collector observed it, it got thrown away either way.
In the end, this reminds me of my own failing using background tasks in .Net.
[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!Antarctic Glacier Saw the Fastest Retreat In Modern History
Read more of this story at Slashdot.
LADWP Says It Will Shift Its Largest Gas Power Plant To Hydrogen
Read more of this story at Slashdot.
Spotify Sued Over 'Billions' of Fraudulent Drake Streams
Read more of this story at Slashdot.
Ukraine First To Demo Open Source Security Platform To Help Secure Power Grid
Read more of this story at Slashdot.
AMD Will Continue Game Optimization Support For Older Radeon GPU's After All
Read more of this story at Slashdot.
