We pay for user submitted tutorials and articles that we publish. Anyone can send in a contributionLearn More
Let me share you with one of the weirdest errors I ever encountered. Recently, I have been working on a distributed application which is built from a server and some clients. The clients are Windows Forms applications. Yesterday, I spent a whole day chasing a very weird and strange error – I was getting an exception at the main method (unhandled exception) of the client application. Here is what I got:
The error description was:
Getting an array length in C# is a trivial task. All we need to so is call the Length property of the Array Class:
int arr = new int; int arrLength = arr.Length;
Getting an array length in C++ might be less trivial:
int arr; int arrSize = sizeof(arr) / sizeof(int);
Notice that sizeof(arr) returns the array size in bytes, not its length…
We all know what breakpoints are, they tell the debugger that an application should break and pause execution, at a certain point. If we want to get certain information at this point, we need to copy it down to a paper or to the notepad. There are breakpoints which get hit hundred of times during the execution of a program, so it may be very exhausting to write down the breakpoint information each time it is hit. Well, last week, while I saw John Cunninghams session at PDC 2008 about Visual Studio Debugger Tips & Tricks, I learned something new. The Visual Studio debugger has another feature called tracepoints.
From Wikipedia: “A deadlock is a situation wherein two or more competing actions are waiting for the other to finish, and thus neither ever does”. Deadlocks are terribly difficult to find and even more difficult to debug. Debug Inspector is a free tool that allows you to view the call stacks of multiple threads at the same time, plugs in to the internals of the CLR and automatically detects deadlocks.
The most powerful feature of this tool is that it works on both managed and unmanaged code. It is actually a Visual Studio extension which can be used to detect managed deadlocks and a standalone executable to detect unmanaged deadlocks. Besides detecting deadlocks, there are more features to this tool:
If you have read the Unhandled Exceptions – Handle Them article, you are already familiar with unhandled exceptions in C#. Most people don’t really know that C++ also, have a mechanism to allow a clean termination of our program. I am writing this post to introduce you with that mechanism.
When an exception is unhandled by our program, no cleanup occur, meaning the destructors are not called. Moreover, you may want to do operations such as logging or presenting a friendly screen announcing about the occurrence of a problem. Wrapping out Main function with a Try Catch(…) block is not recommended due to performance issues. Fortunately, the…
Today I am going Alvin Ashcrafts and Chris Alcocks way and publish a lists of blog posts I liked. I don’t tend to do this a lot and actually, this is only the second time. So, here is the list of posts which I liked reading and wanted to share with you:
Is it OK to throw exceptions from constructors? Some of us may have heard that it is wrong but don’t really remember why. There are lots of philosophical arguments about this question, you may become confused trying to understand what’s the right thing to do. Does it mater if we are developing with C++ or any other .Net language like C#? I am writing this article to shed some light on the “throwing exceptions from constructors” topic.
Constructors can’t return values, so we pretty much have to throw an exception to indicate that the object couldn’t be constructed. Some of you may grasp that constructors are supposed to handle simple tasks…
This is part B of the 10 Ways To Programaticly Shoot Yourself In The Foot article. As I already stated in part A, there are several things a software developer can do to make his life much more difficult in the future. In this article I will talk about another 5 issues that even the best developers have to be aware of. In other words, I will try to prevent you from programaticly shooting yourself in the foot.
There are four access modifiers: public, protected, internal and private. Don’t use public everywhere you can! Choose the correct access modifier!…
For the last month, I was working on an imagery infrastructure library. Some of my effort was to well document each class, method and property so that the users of this library will have the privilege of knowing how to properly use it. During the development phase, I created a test project so I will be able to test my code at runtime. By the end of this month, I decided to separate the test project from the main solution and create a test solution. Surprisingly, when browsing the test code and hovering my library classes and methods, no comments appeared in the Visual Studio tooltip:
Those comments did appear when the test and the imagery infrastructure projects belonged to the same solution. On In this article, I am going to explain why it is so important to generate XML documentation file for each one of your .Net projects.
There are several things a software developer can do to make his life much more difficult in the future. One day, some pieces of an old code may make us sorry we haven’t dedicated some more effort when we wrote it, so we have to pay attention and be careful. I am not talking about bad developers who always generate bad code because in those cases, every piece of their code is a disaster. Amit is talking about this issue in Terrible Code Examples – Methods From Hell. In this article I will point out some more .NET advanced issues that even the best developers have to be aware of. There are some things you can do which will cause some problems later on and you will be the one who have to handle with those issues. In other words, I will try to prevent you from shooting yourself in the foot.
Copyright © 2012 Dev102.com
Breeze : Designed by Amit Raz and Nitzan Kupererd