Index Out Of Bounds

IE8 – Developer Tools Broken

Posted on March 20th, 2009 admin No comments

So I tried using the IE8 developer tools this morning (after my upgrade yesterday) and happened to be working on a page the was doing a few console.log calls (lots of ajax calls in the background I was trying to debug).

I noticed that if I refreshed the page (since I was changing code) the console window didn’t clear itself (okay, fine – could be useful) but I noticed that it kept getting slower and slower.

So I wrote quick test to see what was going on – looks like there is some very broken code in IE8s console window (see my video below) (all I’m doing is a window.setInterval() with a console.log():

You can see where I stop the log, and it’ll catch up but it gets incrementally slow with each log entry…

Programming
Make your constants “Discoverable” IntelliSensically

Posted on March 14th, 2009 admin No comments

The other day, I was working on some legacy code that had some sort of master class containing a lot of static properties (to avoid magic numbers of course).

You all have seen a class like this before right?
```
   1: public static class Constants
```
```
   2: {
```
```
   3:     public static string PersonTableName
```
```
   4:     {
```
```
   5:         get { return "Person"; }
```
```
   6:     }
```
```
   7:  
```
```
   8:     public static string PersonTableIdColumn
```
```
   9:     {
```
```
  10:         get { return "PersonId"; }
```
```
  11:     }
```
```
  12:  
```
```
  13:     public static string PersonTableFirstNameColumn
```
```
  14:     {
```
```
  15:         get { return "FirstName"; }
```
```
  16:     }
```
```
  17:  
```
```
  18:     public static string PersonTableLastNameColumn
```
```
  19:     {
```
```
  20:         get { return "LastName"; }
```
```
  21:     }
```
```
  22:  
```
```
  23:     // ... 50 more entries full of table names and columns ...
```
```
  24: }
```
Okay, so assume here that I couldn’t create a real Doman Layer and refactor all this code out.

One of the other “code smells” was that it doesn’t lend itself to being discoverable.

So for example. If I were writing some code that referenced this monstrosity, I’d start by typing: “Constants.” and Intellisense would bring up 100 billion properties I didn’t care about…

Instead, I decided I could easily make this code a bit more organized and much more discoverable by creating some inner classes and grouping things that way:
```
   1: public static class Constants
```
```
   2: {
```
```
   3:     public static class Tables
```
```
   4:     {
```
```
   5:         public static class Person
```
```
   6:         {
```
```
   7:             public const string Name = "Person";
```
```
   8:  
```
```
   9:             public static class Columns
```
```
  10:             {
```
```
  11:                 public const string Id = "Id";
```
```
  12:  
```
```
  13:                 public const string FirstName = "FirstName";
```
```
  14:  
```
```
  15:                 public const string LastName = "LastName";
```
```
  16:             }
```
```
  17:         }
```
```
  18:  
```
```
  19:  
```
```
  20:         public static class Company
```
```
  21:         {
```
```
  22:             public const string Name = "Company";
```
```
  23:  
```
```
  24:             public static class Columns
```
```
  25:             {
```
```
  26:                 public const string Id = "Id";
```
```
  27:  
```
```
  28:                 public const string CompanyName = "Name";
```
```
  29:             }
```
```
  30:         }
```
```
  31:     }
```
```
  32: }
```
Looking at the code, I had a much better feeling about it. The natural flow of the inner classes made reading and finding the constants much easier and you didn’t have to worry about dissimilar items being bundled together in a massive source file.

With IntelliSense, things look so much better:

.NET, C#, Programming
Keep Exceptions exceptional Part 2

Posted on June 25th, 2008 admin No comments

SharePoint seems to be really bad with weird Exceptions, plus I’m working on a SharePoint solution right now, so I’m going to pick on them some more today.

I was writing some SharePoint event-handler code, where after a list item was updated, the code would fire off (ItemAdded event) and do some processing on the list item. In development on a machine with one processor, everything seemed to be working fine. However, in the farm in production, all sorts of things blew up.

Now here is the kicker. This was the actual exception thrown:

COMException (0×80004005): Cannot complete this action.
Please try again.

Say what!? First off, why is SharePoint still using COM? But secondly, why throw an exception that contains zero information about what really went wrong – and then in the text of the exception say “Please try again.” If it can be tried again, I want it to actually TRY AGAIN for me.

So I guess my point is that if you are going to throw an Exception. Make the text informative and explain why the exception was being thrown. Additionally, don’t put UI specific text in framework Exceptions (I’m guessing the “Please try again” was meant for the end-user to try re-submitting a check-in or something).

Programming, SharePoint
Keep Exceptions for cases that are exceptional.

Posted on June 21st, 2008 admin No comments

I’ve been writing some SharePoint code lately and for some reason they fell into a pattern of throwing Exceptions for the worst reasons. I had a case where I wanted to determine if a user was part of a group. Unfortunately, the SPGroup object doesn’t have any way to check for existence of a user. I had to come up with a workaround. There were two ways I could go about this. The first non-optimal way would be to loop through all the SPUsers in the SPGroup:
```
   1: SPUser user = GetSomeUser();
```
```
   2: SPGroup group = RootWeb.Groups["mygroup"];
```
```
   3: foreach (SPUser groupUser in group.Users)
```
```
   4: {
```
```
   5:     if (groupUser.Equals(user))
```
```
   6:     {
```
```
   7:         // Found user
```
```
   8:         break;
```
```
   9:     }
```
```
  10: }
```
But code like that makes me cringe. If the user doesn’t exist, I end up going through all the users in the group and knowing how SharePoint works, that means making a lot of calls the SQL to get and hydrate all the SPUser objects.

Here is an example of the code I wrote:
```
   1: SPUser user = GetSomeUser();
```
```
   2: SPUser foundUser = RootWeb.Groups["mygroup"].Users.GetById(user.ID);
```
```
   3: if (foundUser != null)
```
```
   4: {
```
```
   5:     // Do Something
```
```
   6: }
```
My thought was “Hey, I’ll just try and get the user, and if it returns null I know they exist in the group.” In actual execution, the above code failed with a SPException when the user didn’t exist in the group. Reading the documentation, I wasn’t expecting this. So I broke out Reflector (A must when trying to comprehend the SharePoint object model) and saw this code:
```
   1: public SPUser GetByID(int id)
```
```
   2: {
```
```
   3:     SPUser byIDNoThrow = this.GetByIDNoThrow(id);
```
```
   4:     if (byIDNoThrow == null)
```
```
   5:     {
```
```
   6:         throw new SPException(
```
```
   7:             SPResource.GetString("CannotFindUser",
```
```
   8:                                  new object[0]));
```
```
   9:     }
```
```
  10:     return byIDNoThrow;
```
```
  11: }
```
So, somebody thought it would be a good idea throw an SPException if the user didn’t exist in the group!? I’ll get back to this in a minute, but first I want to note that there is a method that doesn’t throw an exception and this code was calling it – only problem is that somebody decided that they would make the scope internal. Conspiracy theorists might think that Microsoft was purposely making programming with SharePoint hard for everyone but them…

Okay, so back to throwing an SPException – I’m going to point out how absolutely bone-headed this design pattern is. Here is the code I’d have to write to handle the non-existence of a user:
```
   1: try
```
```
   2: {
```
```
   3:     SPUser foundUser = group.Users.GetById(user.ID);
```
```
   4:     if (foundUser != null)
```
```
   5:     {
```
```
   6:         // Do Something
```
```
   7:     }
```
```
   8: }
```
```
   9: catch (SPException)
```
```
  10: {
```
```
  11:     // User not found.
```
```
  12: }
```
So, I’ve expanded my code by having to put a try-catch in there. However, this code introduces a giant bug. The problem is that a SPException being thrown doesn’t necessarily indicate that the SPUser isn’t in the SPGroup – It means that an Exception occured somewhere (maybe SharePoint couldn’t connect to the DB or something). So I was faced with a dilemma – I could either go with the buggy code, the slow inefficient code, use reflection to call the internal GetByIdNoThrow() method or search for some other way to check for the user’s existence.

All of this because someone was shortsighted and didn’t write something like group.Users.Contains(user);. Ah well, it gave me some insight into one possible reason why SharePoint is so freaking slow.

.NET, C#, Programming, SharePoint
Hello world!

Posted on February 12th, 2007 admin No comments

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

Uncategorized

Calendar

Archives

Recent Articles

Links

Categories

.NET (2)
C# (2)
Programming (4)
SharePoint (2)
Uncategorized (1)

Meta