X

Aggregator

Australians To Get At Least Three Hours a Day of Free Solar Power - Even If They Don't Have Solar Panels

Slashdot
2 months 2 weeks ago
Australia's new "solar sharer" program will give households in NSW, south-east Queensland, and South Australia at least three hours of free solar power each day starting in 2026 -- even for those without rooftop panels. Other areas will potentially follow in 2027. The Guardian reports: The government said Australians could schedule appliances such as washing machines, dishwashers and air conditioners and charge electric vehicles and household batteries during this time. The solar sharer scheme would be implemented through a change to the default market offer that sets the maximum price retailers can charge customers for electricity in parts of the country. The climate change and energy minister, Chris Bowen, said the program would ensure "every last ray of sunshine was powering our homes" instead of some solar energy being wasted. Australians have installed more than 4m solar systems and there is regularly cheap excess generation in the middle of the day. Part of the rationale for the program is that it could shift demand for electricity from peak times -- particularly early in the evening -- to when it is sunniest. This could help minimize peak electricity prices and reduce the need for network upgrades and intervention to ensure the power grid was stable.

Read more of this story at Slashdot.

BeauHD

Undefined Tasks

The Daily WTF
2 months 2 weeks ago

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 crashes

This 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!
Remy Porter