#scrapoverflow

System.Collections.Generic Namespace

The System.Collection.Generic namespace was introduced in .NET 2.0 and provided collections and interfaces which guaranteed type-safety. This meant that, for example, a List<string> could only hold string objects. This may seem like a step backwards since ArrayLists can hold any object type but there are performance and stability gains.

Performance

Let's say that a List<T> will replace your ArrayList (they're used in a similar manner so it's likely to be the closest replacement you're looking for). Since a List can only hold one type, there's no need for casting from object type to any other type. ArrayLists can only store object types, so there's constant casting when you retrieve an object from it.

This casting to and from object is particularly expensive when you look at value types (int, bool, enum, floats etc..). Value types need to be boxed when being stored as an object type and unboxed when being retrieved. These are relatively expensive operations which List<T> never has to do because it doesn't store elements a object types (unless, for example, you create a List<object>).

Essentially Lists<T> are faster in general use so that's a big advantage.

Stability

Since List<T> can only store one type (whatever type T is), you know exactly what type to expect when you read from it. So you can safely do this

List<int> myList = new List<int>(); myList.Add(13); myList.Add(37); foreach(int i in myList) { int myInt = i; }

You can be sure that this code is fine because you know that myList will only contain int types. There's no need to do any explicit checking of whether or not i is an int and there's no unboxing involved when reading from the list.

With an ArrayList, you run the risk of accidentally trying to cast to the wrong type which could throw an exception (and exception handling is also an relatively expensive procedure). For example, this would throw an InvalidCastException and whilst this piece of code is obviously wrong, it's not difficult to make a similar mistake in a slightly more complex case.

ArrayList myArrayList = new ArrayList(); myArrayList.Add(13); //insert int myArrayList.Add("37"); //insert string foreach (object o in myArrayList) { int t = (int)o; //exception thrown for "37" }

Mistake 1 - Throwing a new exception  Throwing a new exception is pointless if you're hoping to get any information. It creates a new exception object and throws it, which means you lose the stacktrace and any information about the actual exception that was thrown.

try { } catch (Exception ex) { throw new Exception(); //bad }

Mistake 2 - Throwing the exception object This method might look intuitive but it's slightly deceptive. In Java this would be fine but in C# this loses the original stacktrace and replaces it with a new one that starts from this point (which you likely don't want, you'd rather have the original stacktrace) 

try { } catch (Exception ex) { throw ex; //bad }

Recommended approach - Use throw; Not only does this require the least typing but it also provides the most information. The exception object that is caught is thrown, like the second mistake, but the original stacktrace is maintained so you have as much information as possible about the exception and what lead up to it.