admin

Command Line Snippet (from Scott Hanselman of course!)

by

So I’m watching yet another great Hanselman webcast, and he casually mentions that if you hit ‘F7‘ in a command prompt window (cmd.exe), you get a history list of all your commands…wait a minute rewind that! I knew about the history list and the up/down cursor keys (as I’m assuming everyone does right?), but ‘F7’? And what do you know, the folks responsible for PowerShell have also included it!

CSS Control Adaptor Toolkit: Update Available

by

A recent on-going trend in web page design is for page layout to use pure CSS based layout instead of TABLE elements. [See References Zen Garden, Free CSS layouts for just a few examples.]

What are Control Adaptors? ASP.NET 2.0 has a new extensibility model built into it called Control Adapters. Control adapters allow you to plug into any ASP.NET server control through this model and override, alter or tweak how that control is rendered.

The great thing about control adaptors is they do not require developers to change the way they program against existing controls or to use new controls on a page. In fact, the developer can be completely unaware that a control adaptor is being used, because the control adaptor encapsulates all the functionality required. The ASP.NET 2.0 CSS control adaptor white paper can be found here.

A new Beta2 of the control adaptor toolkit is available and you can download it from here.

Scott Guthrie’s original article is here: CSS Control Adapter Toolkit for ASP.NET 2.0. His update article CSS Control Adapter Toolkit Update contains a Quick Start walkthrough. Excellent stuff!

.NET Exception Handling Guidelines: Catching Exceptions (part 4)

by
  • Unless you are writing framework code, do not consume non-specific errors by catching System.Exception or System.SystemException.
  • There are occasional circumstances when swallowing errors in applications are justified, but these are few and far between.
  • Do NOT over catch. Over-catching can hide bugs. Let exceptions propagate up the call stack.
  • Catch specific exceptions only when you know you can recover from them. Do NOT catch exceptions you can do nothing about.
  • If you can avoid throwing an exception, by using a TryParse, Exists or some other method, do so.
  • Use try-finally rather than try-catch for cleanup code.
  • For objects that implement IDisposable consider the using statement:
using (SqlConnection connection = new SqlConnection(connectionString))

{

}

  • Try to avoid catching and rethrowing: it can decrease the effectiveness of debugging.
  • If you do catch and rethrow an exception, use an empty throw rather than throw ex, otherwise you will lose the original exception’s call stack:

try

{

    //…code that might throw here…

}

catch (CustomException ex)

{

    // perform some specific handling here…

    throw; //rethrow the original exception

}

The links to the previous posts on this topic are here: part 1, part 2, part 3.

.NET Exception Handling Guidelines: Custom Exceptions (part 3)

by
  • Derive custom exceptions from System.Exception or one of the other base exception types (but not System.ApplicationException).
  • Suffix custom exception type names with “Exception”
  • Make exceptions serialisable, so they can cross remoting and application domain boundaries.
  • Provide the following constructors on all custom exceptions, and use the same parameter names and types:

[Serializable]

public class CustomException : Exception, ISerializable

{

public CustomException(){}

public CustomException(string message) { }

public CustomException(string message, Exception inner) { }

// This is required for serialisation

protected CustomException(SerializationInfo info, StreamingContext context) { }

}

part 1, part 2, and part 4 are here.

.NET Exception Handling Guidelines: Throwing Exceptions (part 2)

by

Exceptions are aptly named! Throw them in exceptional circumstances. A public method represents a contract with consumers. A method should raise an exception whenever it cannot successfully complete the task that its name implies it was designed to accomplish.

  • Report execution failures by throwing exceptions; do NOT return error codes.
  • Do NOT use exceptions for the normal flow of execution, if at all possible.

Don’t do this!:

foreach (Item i in someList)

{

try

{

someOtherList.Add(i);

}

catch

{

// swallow failures, where i already exists in someOtherList…

}

}

  • Create exceptions sparingly. Wherever possible, throw existing exceptions (from the System namespaces), rather than creating new ones.
  • Create and throw custom exceptions in situations where an error condition can be handled in a more specific way than existing exceptions.
  • Always throw the most specific exception that is applicable.
  • When throwing an exception, provide a descriptive and useful message, explaining the cause of the exception. Since exception messages are only relevant when an exception is unhandled, the message text should be aimed at helping developers fix the bug.
  • Check for bad arguments supplied to methods and throw ArgumentException, ArgumentNullException and ArgumentOutOfRangeException exceptions where appropriate. Set the ParamName property when throwing one of these. Code should almost never need to catch any of the Argument exceptions.
  • Do NOT throw System.Exception or System.SystemException
  • Do NOT throw OR derive from System.ApplicationException
  • Do NOT throw CLR exceptions.

part 1, part 3 and part 4 are here

.NET Exception Handling Guidelines

by

As a developer, some of the books I have on hand get read and re-read (partly due to low retention!). One such book is the Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina; every .NET developer should have a copy of this within arms reach! After a discussion about exception handling best practices with another developer, I went back to this book for a re-read…and coincidently the same day, Scott Hanselman had made a post about the same topic. (I’m going to post this in 4 parts rather than one large post…)

The benefits of using exception handling over error return value based reporting are:

  • Exceptions promote API consistency, because they are designed for the sole purpose of error reporting. In contrast, error return codes can be easily ignored or overlooked.
  • Exceptions integrate well with object-oriented languages. When you have no control over error return values (in operator overloads, for example), an out of band mechanism is required.
  • With exception based error reporting, error handling code does not have to be close to the point of failure. In fact, developers have a choice of where to site the error handling code.
  • Exceptions can make your production code more robust than equivalent code that ignores error return values, because more problems will be caught during testing.
  • Exceptions can have rich textual error information describing the cause of the failure rather than some obscure error number.

Although you should not use return codes to indicate failures, you can still return status information for successful operations (such as returning the number of records inserted).

part 2, part 3 and part 4 are here.

IronPython v1.0 Released

by

As this happened 2 days ago now, it’s probably old news! IronPython v1.0 for .NET has been released. You can download the binaries, source code, and tutorials from CodePlex here.

This latest release utilises some of the new dynamic language features added to the CLR in version 2.0 of the .NET framework.