William Bartholomew

Michael Kaplan’s post “y? Because it’s documented that way!” raises a good point about undocumented behaviour. Basically, just because it works doesn’t mean you should, unless it’s documented that is. If you rely on undocumented behaviour you are exposing yourself to a higher level of risk when the API you use is revised.

Whether one looks at the Custom Date and Time Format Strings used by things like DateTime.ToString(string) or the strings in GetDateFormat or the strings in GetTimeFormat, it is clear that some characters (like H and M) have specific meaning attached to the cased variants.

In my book, since only the lowercase y is used here, the uppercase behavior is undefined — if it works then have fun but you really shouldn’t; if it fails then you kind of asked for that failure….

And more importantly, if the meaning changes in the future then that is also something requested in the improper use. and the nature of H vs. h and M vs. m kind of underscores this.

When building applications that will run unattended (for example from a scheduled task or a Windows Service) you usually need to be quite aggressive when catching exceptions. This can be quite detrimental to the debugging experience and there are two common workarounds to this problem:

Configuring Visual Studio to Break When Exceptions Are Thrown

By default Visual Studio will break when exceptions are unhandled, but if you have aggressive exception handling then most exception will be handled and Visual Studio will never break. You can configure Visual Studio to break when an exception is thrown rather than only if it’s unhandled from the Debug | Exceptions menu. This shows the dialog below which allows you to choose for each exception type under which circumstances Visual Studio will break.

Adding Breakpoints Manually

The alternative is to manually add breakpoints in the exception handlers you’re interested in debugging as shown here:

But Wait… There Is Another Option

Visual Basic allows you to add a filter to your exception handlers specifying a condition under which the exception handler will be in effect.

We can leverage this to make our handler only catch the exception if there isn’t a debugger attached which means if a debugger is attached the exception will be unhandled and the debugger will automatically break.

We use the shared IsAttached method of the Debugger class in the System.Diagnostics namespace to detect if a debugger has been attached as shown in this example:

Try
    teamFoundationServer.EnsureAuthenticated()

Catch ex As TeamFoundationServerException When Not Debugger.IsAttached
    My.Application.Log.WriteException(ex)
    Environment.Exit(ExitCode.TeamFoundationServerExceptionAuthenticating)

Catch ex As WebException When Not Debugger.IsAttached
    My.Application.Log.WriteException(ex)
    Environment.Exit(ExitCode.WebExceptionAuthenticating)

End Try