We Keep Coding

Getting the original error message out of an ArgumentException

When writing classes for internal processing in .Net, I often use ArgumentException to indicate something is wrong with the given data and it can't be processed. Due to the nature of the program, the text I put in these exceptions is sometimes relevant to the user, and so it often gets shown on the UI.
However, I noticed that ArgumentException specifically overrides the Message property to append its own string to indicate which argument caused the exception. I don't want this extra text polluting the message, since the actual argument name is internal processing info that really doesn't need to be shown to the user, and the fact it adds a line break, and that it is localised, messes up the formatting of the message I show on the UI. The only way to get around this is to not give the exception the actual argument name, but I don't want to sabotage my own debugging / logging by removing that information, either.
I could use my own exception class, of course, but since a lot of these methods are for compression and decompression of proprietary file formats in old DOS games, and I want these methods to both be documented on a wiki and be generally easily usable by anyone else, I'd prefer keeping them portable and avoid reliance on other external classes. And, as a side note, subclassing ArgumentException would of course give the same issue.
The original source:
public override String Message
{
get {
String s = base.Message;
if (!String.IsNullOrEmpty(m_paramName)) {
String resourceString = Environment.GetResourceString("Arg_ParamName_Name", m_paramName);
return s + Environment.NewLine + resourceString;
}
else
return s;
}
}
(from referencesource.microsoft.com)
Since this actually overrides the Message property, there seems to be no normal way to get to the real message that's stored internally. Splitting on a line break seems messy and potentially unreliable depending on localisation differences (and the message I give it might potentially have line breaks already), and using reflection for this seems rather messy. Is there a clean way to recover the original message?
(Posting this here with solution for documenting reasons, since this behaviour really frustrated me when I encountered it)

Since I didn't want to dig into reflection, I figured a good way to get the original data without the associated class behaviour would be to serialize it. The names of the properties in the serialised info are very straightforward, and can be accessed without the ArgumentException getter mangling it with its own additions.
The code to accomplish this turned out to be pretty straightforward:
public static String RecoverArgExceptionMessage(ArgumentException argex)
{
if (argex == null)
return null;
SerializationInfo info = new SerializationInfo(typeof(ArgumentException), new FormatterConverter());
argex.GetObjectData(info, new StreamingContext(StreamingContextStates.Clone));
return info.GetString("Message");
}

A better way to handle NullReferenceExceptions in C#

I recently had a coding bug where under certain conditions a variable wasn't being initialized and I was getting a NullReferenceException . This took a while to debug as I had to find the bits of data that would generate this to recreate it the error as the exception doesn't give the variable name.
Obviously I could check every variable before use and throw an informative exception but is there a better (read less coding) way of doing this? Another thought I had was shipping with the pdb files so that the error information would contain the code line that caused the error. How do other people avoid / handle this problem?
Thanks

Firstly: don't do too much in a single statement. If you have huge numbers of dereferencing operations in one line, it's going to be much harder to find the culprit. The Law of Demeter helps with this too - if you've got something like order.SalesClerk.Manager.Address.Street.Length then you've got a lot of options to wade through when you get an exception. (I'm not dogmatic about the Law of Demeter, but everything in moderation...)
Secondly: prefer casting over using as, unless it's valid for the object to be a different type, which normally involves a null check immediately afterwards. So here:
// What if foo is actually a Control, but we expect it to be String?
string text = foo as string;
// Several lines later
int length = text.Length; // Bang!
Here we'd get a NullReferenceException and eventually trace it back to text being null - but then you wouldn't know whether that's because foo was null, or because it was an unexpected type. If it should really, really be a string, then cast instead:
string text = (string) foo;
Now you'll be able to tell the difference between the two scenarios.
Thirdly: as others have said, validate your data - typically arguments to public and potentially internal APIs. I do this in enough places in Noda Time that I've got a utility class to help me declutter the check. So for example (from Period):
internal LocalInstant AddTo(LocalInstant localInstant,
CalendarSystem calendar, int scalar)
{
Preconditions.CheckNotNull(calendar, "calendar");
...
}
You should document what can and can't be null, too.

In a lot of cases it's near impossible to plan and account for every type of exception that might happen at any given point in the execution flow of your application. Defensive coding is effective only to a certain point. The trick is to have a solid diagnostics stack incorporated into your application that can give you meaningful information about unhandled errors and crashes. Having a good top-level (last ditch) handler at the app-domain level will help a lot with that.
Yes, shipping the PDBs (even with a release build) is a good way to obtain a complete stack trace that can pinpoint the exact location and causes of errors. But whatever diagnostics approach you pick, it needs to be baked into the design of the application to begin with (ideally). Retrofitting an existing app can be tedious and time/money-intensive.

Sorry to say that I will always make a check to verify that any object I am using in a particular method is not null.
It's as simple as
if( this.SubObject == null )
{
throw new Exception("Could not perform METHOD - SubObject is null.");
}
else
{
...
}
Otherwise I can't think of any way to be thorough. Wouldn't make much sense to me not to make these checks anyway; I feel it's just good practice.

First of all you should always validate your inputs. If null is not allowed, throw an ArgumentNullException.
Now, I know how that can be painful, so you could look into assembly rewriting tools that do it for you. The idea is that you'd have a kind of attribute that would mark those arguments that can't be null:
public void Method([NotNull] string name) { ...
And the rewriter would fill in the blanks...
Or a simple extension method could make it easier
name.CheckNotNull();

If you are just looking for a more compact way to code against having null references, don't overlook the null-coalescing operator ?? MSDN
Obviously, it depends what you are doing but it can be used to avoid extra if statements.

How to detect if element exist using a lambda expression in c#?

I've been using a try/catch statement to run through whether or not an element exists when I parse through it. Obviously this isn't the best way of doing it. I've been using LINQ (lambda expressions) for the majority of my parsing, but I just don't know how to detect if an element is there or not.
One big problem with some solutions I found is that they take 3-4 times more code than using the try/catch block, which kind of defeats the purpose.
I would assume the code would look something like this:
if(document.Element("myElement").Exists())
{
var myValue = document.Element("myElement").Value;
}
I did find this link, but the looping is unecessary in my case as I can guarantee that it will only show up once if it exists. Plus the fact of having to create a dummy element which seems unecessary as well. Doesn't seem like it's the best way (or a good way) of checking. Any ideas?

XElement e = document.Element("myElement");
if (e != null)
{
var myValue = e.Value;
}
http://msdn.microsoft.com/en-us/library/system.xml.linq.xcontainer.element.aspx
"Gets the first (in document order) child element with the specified XName."
"Returns Nothing if there is no element with the specified name."

Any() is the Linq command.
Assert.IsFalse( new [] { 1, 2, 3, 4 }.Any( i => i == 5 ));

Btw, the comment above about "try / catch" can be true, but isn't in almost all cases. It depends on how you build your solution. In your Release build, turn off as much flags as possible that smell like "Debug" even from a distance. The less the runtime has been told to memorize stack traces and stuff during building, the faster "try / catch" becomes.
Btw, #2: The famous architectural patterns "Tell, don't ask!" (TDA) and the "Open Close Principle" (OCP) forbid the usage of such infamous code like "if (!(fp = fopen(...))". They don't just encourage you to use "try / catch" but force you to do so. Because the OCP not only demands to obey within your own code but also when calling foreign stuff (i.e. libraries like stdio).
Why OCP, not TDA in the last sentence? Because you're not allowed to widen the meaning of existing code. Sticking to the simple "fopen" example, what are you going to do when the result is Zero? Why exactly did "fopen" fail? You could check wether there's enough empty space left, or if the file system is writeable. Of if the file name is valid. Or whatnot. Still, your goal cannot be achieved: open the file. Imagine a headless application, so no intervention of the user is possible. Now what? There is exactly no reason to further fumble with the stuff, because "fopen" failed. You'll need a fallback strategy. Dot. If "fopen" has failed, it has failed.
Rule of thumb: Think of your code as always succeeding (KIS). If your code willingly may 'fail' in terms of that a result set regularly may contain elements or not, put the logic into the class. Perhaps you have to distribute data, properties, and questions, and methods across different classes (TDA). Perhaps you have to readjust your code according to SLA.
In your case, though, make sure the element is existing. If you cannot, it's not your fault. Deep down in your code (a wrapper where all the mistakes of former coders get beautified), transform the data needed into another entity such that further up there is no need to "if".

Any() is the simplest way to check if an element exists.
If you have to make sure that the element is unique, you'll have to do something like .Count() == 1. Alternatively you could implement your own extension method, but this would be only a wrapper around .Count == 1.

Is it possible to delete or insert frames into the C# call stack?

Using StackTrace I can get the stack frames. My question is whether it is possible to manipulate the call stack in C#? More specifically: Is it possible...
to insert a frame into the call stack? or
to delete a frame from it?

Stack is a very internal component of program's runtime. Having the ability to alter it would make it possible to:
Make almost unrestricted goto's. Something that is considered a very bad programming practice and is not possible even in PHP. Debugging such thing would be a complete mess.
Inject code on method returns. This may be useful, but is already covered by aspect oriented tools, like PostSharp or Spring.NET, which allow you to do this in clean and predictable way. And they cover much more cases than just method returns.
Thus, I do not think there is any programming language that allows you to manipulate stack explicitly. It would make things very messy and any benefits it may produce are already covered by Aspect-Oriented-Programming. I bet AOP will make you able to achieve what you want.

It is easy to manipulate the stack in Smalltalk, but I don't think it is possible in C#.

StackTrace class doesn't support this kind of manipulation. Frames are read only as per msdn (only GetFrame, GetFrames methods are available).
To see how the class is created by framework you can have a look directly into source code of the class.

No, it is not possible. The Stack Is An Implementation Detail.
Moreover, the ability to manipulate the stack will bring a LOT of security/consistency issues. This is why manipulating the stack is a bad practice/a security bug even when you can do it (in C, for example). For example,the infamous "buffer overflow" category of security issues spring exactly from this: the ability to insert a "goto", a new stack frame, into the code, so that upon return a malicious payload is executed instead of the legitimate calling function.
But then, why would you like to do it? Given a real goal, we could better reason how to do that, and suggest good alternatives

Yes, you can via Reflection.
Ultimately it's a string.
The following is an exception class for logging Javascript exceptions with the javascript stacktrace as a C# exception, preserving the original stack trace.
using System.Reflection;
public class JsException : Exception
{
static readonly FieldInfo _stackTraceString = typeof(Exception).GetField("_stackTraceString", BindingFlags.GetField | BindingFlags.NonPublic | BindingFlags.Instance);
public JsException(string error, string stack)
: base(error)
{
_stackTraceString.SetValue(this, stack);
}
}

Using Exception.Data

How have you used the Exception.Data property in C# projects that you've worked on?
I'd like answers that suggest a pattern, rather than those that are very specific to your app.

The exception logger I use has been tweaked to write out all the items in the Data collection. Then for every exception we encounter that we cannot diagnose from the exception stack, we add in all the data in that function's scope, send out a new build, and wait for it to reoccur.
I guess we're optimists in that we don't put it in every function, but we are pessimists in that we don't take it out once we fix the issue.

Since none of the answers include any code. Something that might useful as an addition to this question is how to actually look at the .Data dictionary. Since it is not a generic dictionary and only returns IDictionary
foreach(var kvp in exception.Data) the type of kvp will actually be object unhelpfully. However from the MSDN there's an easy way to iterate this dictionary:
foreach (DictionaryEntry de in e.Data)
Console.WriteLine(" Key: {0,-20} Value: {1}",
"'" + de.Key.ToString() + "'", de.Value);
I don't really know what the format argument , -20 would mean, maybe Take(20)? Digressing... this code can be very helpful in a common error logger to unwind this data. A more complete usage would be similar to:
var messageBuilder = new StringBuilder();
do
{
foreach (DictionaryEntry kvp in exception.Data)
messageBuilder.AppendFormat("{0} : {1}\n", kvp.Key, kvp.Value);
messageBuilder.AppendLine(exception.Message);
} while ((exception = exception.InnerException) != null);
return messageBuilder.ToString();

I have used it when I knew the exception I was creating was going to need to be serialized. Using Reflector one day, I found that Excepion.Data gets stuck into and pulled from serialization streams.
So, basically, if I have properties on a custom exception class that are already serializable types, I implement them on the derived class and use the underlying data object as their storage mechanism rather than creating private fields to hold the data. If properties of my custom exception object require more advanced serialization, I generally implement them using backing private fields and handle their serialization in the derived class.
Bottom line, Exception.Data gives you serialization for free just by sticking your properties into it -- but just remember those items need to be serializable!

I've used it to capture information about the state at the time of the Exception from the enclosing scope as the Exception travels up the stack. Items like the filename that caused the Exception, or the value of some ID that will help track down the problem.
At the top most level in a web application I also tend to add much of the Request information like the RawUrl, the cookies, the Referrer, ...
For more details here's my blog on the topic:
Rather than waiting for problems to happen I add this code in wherever an Exception can occur that's related to something external, e.g. a file name, or an URL that was being accessed, ... In other words, any data that will help repro the problem.

I just tried to use it and found out that it is not very useful for my purpose - so I am not using it.
The most important part of the stack trace is to be able to tell what happened. The method name and line number are great, but you often need to see value of relevant variables in the context of the exception. I thought that was the whole point of the Data. But - you have to see it for it to be useful.
In my case, I control the code around the caught exception but not the code that logs it. So, for me Data is useless if it is not being automatically printed out in the stack trace. I might as well log the values myself rather than add them to the Data. Or, somehow modify the message to add the values in it, so that it gets logged but without losing the original stack trace with line numbers and method names.