Add Additional Information to Your Exceptions

When Enterprise Library was called Microsoft Application Blocks, if you wanted to log an Exception, you would write (assuming “ex” is an Exception):


And if you wanted to log some extended properties you could do something like this:

NameValueCollection customerInfo = new NameValueCollection();

Now that I am upgrading all legacy code to Enterprise Library 2006 for .NET 2.0, I couldn’t find a way to do this since the only way to log an error is:

ExceptionPolicy.HandleException(ex, "General Policy");

where “General Policy” is the name of the Exception Policy in the config file telling the Block what to do with the exception.

Looking in the config file, I noticed a formatter template with the following at the tail end of the template attribute, “…Extended Properties: {dictionary({key} – {value} )}”.  The formatter template is used to format the exception that is about to be logged somewhere.  Looking through the code for where it loops through this Dictionary, I noticed it accessing an IDictionary of Exception.Data.  Exception.Data?  Where did that come from?

Data is a new .NET framework 2.0 property of the Exception class to allow you to add any user-defined information about the exception.  Nothing more to it:  Just a simple name/value dictionary for your enjoyment.  As if you couldn’t figure it out, my new code would look like:

ExceptionPolicy.HandleException(ex, "General Policy");

And as long as you use the default formatter, it will log this data at the end of the FormattedException field.

Fun with #region

I am not sure if I did this on accident, or my intern did it, but I found this in my code:

#region Constructors

//code here

#endregion Constructors

I was not aware you can put a tag after #endregion. Kind of nice to clearly delineate long regions. Not that it really matters, but Visual Studio allows you to put whatever text you want after #endregion, even if it doesn't match the #region label.

Learning C# over VB.NET

I just finished writing a long 'ol email to a friend who wants to do a project in VB.NET since his background is in legacy ASP. Although my points have been illustrated by many over and over, I thought I would post what I wrote in the hopes others can add to my list.

  1. I realize you feel it will be easier for you, but that is only marginally true. What takes time is learning the .NET Framework classes (which were all written in C#, BTW), not the language syntax. For example if you want to get a substring in a string, how would you do it? I doubt you already know that it is:
    string blah = "chad is raicheck";

    blah = blah.Substring(0, 15);

    Dim blah as String = "chad is raicheck"

    blah = blah.Substring(0,15)

    Either way, you won't know how to do it off the bat. Like I said, this is not a VB vs. C# thing. The code is almost identical.

  2. Since you don't know either, it is the same learning curve either way. Believe me, I have had to learn both, and there is MUCH more support from websites, magazines, samples, books, etc with the C# community. Plus I have done pretty much everything in C# and can help you greatly.
  3. The code isn't THAT different once you know the basics.
    Private m_user As User 	'VB
    private User m_user; //C#

    Public ReadOnly Property TotalPosted() As Integer
    Return m_totalPosted
    End Get
    End Property

    public integer TotalPosted
    return m_totalPosted;

    VB is also much more verbose…look how many more words in VB :(. And you can make C# even more compact:

    public integer TotalPosted
    get { return m_totalPosted; }

  4. For the last 4 years I have been adding to my code library and it is ALL C#. That means that even though we are writing our stuff in VB, I will have to spend 3x my time re-writing my website stuff that have already been working and tested.
  5. I am not going to rewrite my code library of thousands of line of C# code. .NET allows us to reference C# dlls from VB, so you will still be accessing C# and most likely having to read C# from my code. In fact, our website solution will have about 3 – 5 projects in it. Our website would be in VB, but then there are common functions classes which is already done in C#, the Data Access Classes that is already in C#, other Microsoft's Data Access Library that everyone uses which Microsoft wrote in C#, Microsoft Enterprise Library's and Exception Handling all in C# (also written by Microsoft). So no matter what, if you are debugging, you WILL be tracing through C# code.
  6. Like I mentioned above, it will take me probably 3x longer to do my job, since I will have to write so much from scratch. That is the equivalent of paying me 3x my regular hourly wage to do C# :(.
  7. It actually will be pretty easy to learn either language since you get to read and see all my code working with my comments of what is happening. I hired a brand new intern who didn’t know C# and I HEAVILY commented things and he caught on really fast.
  8. All my templates that I spent several days writing spits out C# code. I would have to re-write that for VB. In the long run it will still save us time, but it is an added expense.
  9. I said this on the phone, but there are things you just can't yet do in VB that you can in C#. Examples are this:
    //C# this return an object Scott.  This way I can call it by Test.Scott and it returns a "Scott" object
    Class Test
    public Scott Scott
    return m_scott;

    'VB - cant do it, must rename the object so they arent the same name. Now Test.Scott returns an object "ScottObject"
    Class Test

    Public ReadOnly Property Scott as ScottObject
    Return m_scott
    End Get
    End Function

    End Class

  10. THE BIGGEST REASON: I use many tools to help with coding such as: GhostDoc to help with documentation, Jetbrains ReSharper for code support which add HUGE productivity gains. Many of these only work with C#. To not work with ReSharper is like me telling you to not write code with Intellisense. It is that crappy.
  11. There is no XML comments in VB. This is pretty crappy. There are ways to go around it, but none are super perfect.
  12. There are cool things like incrementing shorthand you cant do in VB:
    int i = 0

    i++; //adds 1 to i

    Dim i as Integer = 0

    i = i + 1

Hiding a Row in ASP.NET

Many things that I come across are “No Duh”. This is one of them.

I frequently see code from other programmers that incorrectly use Panel for
the purpose of hiding content. What they don’t understand is that a Panel tag
renders a table, and as such can’t be used around Table Rows. For instance,

  1 <asp:panel id="test" visible="True" runat="server">
  2    Ewoks aren't mini-wookies.
  3 </asp:panel> 

will render as:

  1 <table id="test" cellpadding="0" cellspacing="0" border="0" width="100%"><tr><td>
  2   Ewoks aren't mini-wookies.
  3 </td></tr></table>

that means you can’t do something like:

  1 <tr>
  2 	<th>name:</th>
  3 	<td>something...</td>
  4 </tr>
  5 <asp:Panel ID="test" Runat="server" Visible="True">
  6 	<tr>
  7 		<th>date of birth:</th>
  8 		<td>something...</td>
  9 	</tr>
 10 </asp:Panel>
 11 <tr>
 12 	<th>email:</th>
 13 	<td>something...</td>
 14 </tr>

To do so will create a table between two rows. The reason this has gone
unnoticed by many developers is that they are developing for Internet Explorer
exclusively, which will forgive some of these mistakes. Firefox shows them clear
as day.

I was thinking about a solution this morning, wondering if I would have to
create my own Panel control which renders no table, but thought I would try the
obvious first. Could I just do this?:

  1 <tr>
  2 	<th>name:</th>
  3 	<td>something...</td>
  4 </tr>
  5 <tr id="Tr1" runat="server">
  6 	<th>date of birth:</th>
  7 	<td>something...</td>
  8 </tr>
  9 <tr>
 10 	<th>email:</th>
 11 	<td>something...</td>
 12 </tr>

And then use the following in the code behind?:

  1 protected HtmlControls.HtmlTableRow Tr1;
  3 private void Page_Load(object sender, EventArgs e)
  4 {
  5    Tr1.Visible = false;
  6 }

Sure enough it hid the row!

ReSharper Help and Tutorial

I have found that for me, ReSharper wasn't even close to as great a help until I changed my operating basis regarding how I write code. Many times there are many subtle things you do differently, which just causes pain with ReSharper. It also wasn't easy for me to find and remember all the key combinations. To this day when I can't remember, I just open the Tips it gives during start up and just cycle through them until I find the one I am looking for. (Definately not expeditious since they have a cool PDF reference card now).

So I thought I would write up a quick tutorial on the functions I use most and give some help to those that may not of discovered them or found them not to be as useful.

Optimize Usings


It highlights in gray any using's that aren't being used.


I love de-cluttering and absolutely hate how I find other peoples code declarations (especially in ASP.NET after the designer adds a bunch of stuff you don't reference in the code behind).

Surround With

This is the problem that had me shaking me head. When I code, a lot of time I don't know I need a particular statement until after I write the line of code. It would cause me so much lost time deleting and moving code around. So if I have:

x = 29;

and then I realize I need an “if” surrounding my statement, I would start typing the “if” and as soon as I hit the enter key after the line, it would insert the {} after my “if”, but BEFORE my code, like:

if (x == 0)
x = 29;

What I really wanted it to do was:

if (x == 0)
x = 29;

This is where the “Surround With” feature comes in. Highlight your code (in my case x = 29;), Hit Ctrl+Alt+J, and choose “if”. You get:

if ()
x = 29;

and then it puts the cursor between the paranthesis to do your “x == 0” check.

And of course, you can also define your own “Surround with” macros. I made a few no brainer ones for conversions:

All I do is highlight the “29”, hit Ctrl-Alt-J, hit the “A” key and:

x = Convert.ToInt32(29);