Curly Brace Coder

Far and away improper implementation of exception handlers can be the most insidious source of threading mistakes. Unless the application author implements proper exception handling/handlers, an uncaught exception at minimum can cause a live lock or deadlock, or worst case can terminate the application without cleaning up background threads. In addition, an unhandled exception can leak resources. e.g. in the .NET Framework or Core, Dispose methods will not be called. Here are some common mistakes I've seen: 1) Failure to install application wide AND app domain exception handlers. As noted above, an unhandled exception can cause thread lock or crash the application leaving orphaned threads and resources. Shrink ▲       using System; public class Example { public static void Main() { AppDomain currentDomain = AppDomain.CurrentDomain; currentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler); try {

I've noticed time and again developers who don't quite grok what value there is to using Git for revision control of source. I've witnessed even more developers twist themselves in knots trying to explain and/or defend using Git, or rail against it proclaiming, "What's the big deal? I don't get it...". Here then is my take on Git in a nutshell: The point of GIT, and what it's trying to solve basically boils down to this: 1) The repository lives on your local OS file system. What that offers is a way to version control anything you want (more on text vs. binary ahead), and can sneaker net the entire repository with the copy command without losing version information of changes ! All of the deltas and history are all contained in a nice neat folder named .git. 2) You can also (instead of sneaker net) host the source code on a remote server, which allows anyone with the necessary privileges to pull or commit changes. 3) You can apply filters on what files

I've now seen several articles that discuss converting a Console app to a Windows app without addressing outstanding issues that need to be addressed. I thought this would be a good place to do so. But first, why did the authors intend to do this? Seems that when starting up a Console app, even if you try to hide the Console window, there is a brief (and annoying) flash. I suggested the following: Apparently, there is a warning in the Microsoft docs suggesting to avoid GetConsoleWindow() in that this wont work in future version in Remote Desktop/Terminal Services.  I would counter that if that's the concern, converting to a Windows app makes things worse because stdin , stdout and stderr are closed, which make the application interaction impossible. So let's follow this then and see what issues need to be addressed if we pursue this course of action: 1)   stdin ,   stdout   and   stderr   are sent to   devnull . This isn't just a question of command line parsing, many