Archives
-
Do you need to turn off your PC at night?
I knew there was a reason I still subscribe to the Microsoft At Home and At Work Newsletter.
This morning's edition linked to an article analyzing your PC's power usage at various states--on, off, hibernate, and standby--both the computer and the monitor. Sure, I knew you save power by turning it off, but I hadn't realized (nor thought about it lately) that turning it off and on every day doesn't really hurt much like it used to when I first started using computers (don't make me say how long ago THAT was). Nor did I realize that CRT's use so much more power than flat panels. The bottom line of the article is that turning your PC off indeed saves more power than the other options, but setting it to hibernate overnight is nearly as good.
It also made a frank point that struck the bleeding-heart tree-hugging hippie in me (not to mention my frugal side)--is it worth wasting that energy (and money) to save a few minutes' startup time (to boot, log in, and restore state, such as opening mail, browser, and chat programs) every morning? And, using Windows' hibernate or standby, you don't even take THAT hit. I think Windows default settings have standby and/or hibernate on, but I always turn it off after I install Windows because of that annoyance, not thinking about the consequences.
Time to turn it back on on my computers.
-
ApplicationException obsolete?
As I catch up on finding and adding to NewsGator all the blogs I've missed and shouldn't have, I found the FxCop blog thanks to a recent post by Mitch Denny. I'm a nut for best practices, but admit I don't use FxCop itself as much as I should. I just read up on design guidelines and do my best to implement them, which works out quite well relatively, judging by a lot of other code out there.
In skimming said FxCop blog, I found an entry on ApplicationException. It recommends not throwing ApplicationException in your code, nor deriving any custom exceptions from it, instead using Exception. Now, I've written a fair bit of code and a dozen or so custom exception classes that derive from ApplicationException which was the recommendation from Microsoft and the community, so this news was a bit shocking and hard to understand at first. I posted a long comment there with my feedback before realizing that it'd make a good blog post.
These new recommendations coupled with the fact that ApplicationException is by definition not something the Framework will derive/throw, begs the question: What's the ApplicationException class to be used for now? And if the answer is "nothing," why isn't it marked as obsolete, since the recommendation in Brad's entry came out nearly 18 months ahead of .NET 2.0? Edit: David Kean, who cowrote the FxCop entry, replied and let me know a practical reason that class wasn't marked as obsolete (since it's used as a base class, so marking it obsolete would be a breaking change). So I can understand why it wasn't, but it would still be easier on developers if the compiler gave a warning like it does for other classes that should no longer be used in .NET 2.0.
The post references "several outdated documents floating around on the web (some orginally published by Microsoft)" that still advise deriving all your exceptions from ApplicationException. One pretty significant example of said documents is the official Microsoft .NET Framework documentation.
After thinking about it and reading the applicable parts of Brad's entry a couple times, I can now understand the reasons for Microsoft reversing their advice regarding ApplicationException. I just wonder why the FxCop blog and a couple other blogs were the only ones that said so, and not more high-profile sources like the .NET documentation itself.