The FxCop team recently released a new version, 1.312. Check it out.

I've been working quite a bit lately with the guys responsible for this technology. They've poured a lot of energy into this product... and it shows. With this release, you can expect improved quality of existing rules (reducing false positives, increasing coverage), and a number of entirely new rules. This stuff is based entirely on real experience shipping managed code and is a great way to avoid common implementation mistakes and pitfalls. And it helps you to be consistent with the Framework, too, a real plus when you're shipping publically-consumable APIs.

If you're not already shipping FxCop'd code, I'd highly recommend it... :)

I spent a few minutes tonight updating my exception program to output the EN-US value of any resource strings passed to exception constructors. Find the full updated report for mscorlib here.

Here's an example of what the String.Contains(...) method looks like:

As a follow up to my transitive exception post a little over a week ago, I hacked together a tool that almost does what I want.

See this page for some sample output, the results of running against the Whidbey Beta 1 release of mscorlib.dll (available as a free download off of MSDN). Notice that you get a full stack trace in cases where the method in question doesn't directly throw something, but rather a piece of called code does. It seems to be pretty accurate, and is actually giving me a warm and fuzzy feeling about the state of managed code and exceptions. It doesn't look like we let a lot of crap leak out of methods at all. Having a Java-heavy background, not having checked exceptions is seemingly giving me bouts of paranoia. :)

Here's a quick list of noted exclusions the tool doesn't currently handle at all:

• Late bound method calls. Virtuals, delegates, reflection, and the like.
• Well known system exceptions coming from infrastructure or unmanaged interop.

I have plans for both, but haven't had a chance to get something workable just yet.

You'll also notice that exception constructor arguments are actually captured and output, but only when literals are used at the call site. This is very seldom the case as a result of a little thing we like to call resources that are - thankfully - used pretty ubiquitously throughout the Framework. I'm planning on doing some reflection at the time of analysis to try and tease out the right resource string. I think it's pretty neat to see this data in the report.

I would publish the code for the tool, but unfortunately I've taken a dependency on some "secret-squirrel" (Hi Mark) static analysis technology that can't leave MS's comfy confines.

Diclaimer: This information is for research only, and should not be considered official Microsoft documentation of any sort. Please refer to the .NET Framework SDK for details on exceptions that a given method might throw.

I subjected a friend tonight to the oh-so-exciting task of providing feedback on my book. I'm finding outside input very helpful actually, mostly because the separation of good writing from technical content is an important one to make. Others are good at providing a relatively objective opinion on the words and sentence structure itself. I simply despise the common excuse that just because someone's a nerd, they aren't able to communicate well (or even in a grammatically correct fashion). And they get away with it, too! Not to say that I have mastered these skills yet, but I digress...

Anyhow, here it be:

“This book is so boring, it has to be good.”

KitG posted the Nullable specification just the other day. To me as a Microsoft newbie (yes, I still recall what it's like on the outside), the fact that folks can now readily obtain previews of technologies and read the design specifications is pretty freaking cool... one step closer to complete transparency.

I'm trying to quickly write up a tool to compute the transitive closure of all possible exceptions resulting in an invocation to a given method. Checked exceptions are an interesting means by which to attempt compiler enforcement of this. In Java, for example, exceptions that could be thrown are well known primarily because of strict inheritance rules, removing uncertainty by disallowing overriding methods to declare that they throw new exception types (aside from strengthening through polymorphism). The fact that you must either catch or declare that you throw an exception is simply a way to instruct the compiler what you intend to throw or let seep through the cracks. Arguably it could probably do a decent job (clearly not 100%, though) at figuring it out without requiring you to explicitly state it, however. And then perhaps it just becomes a compiler warning when you don't catch something.

Anyhow, I'm trying to hammer out the logic for my program and I came up with this. It's a bit cryptic, and I've probably used some symbols in uncommon ways... oh well... it helped me to think through the situation, and will be a great help when I actually implement it.

To compute the transitive closure of possible exceptions thrown as a result of an invocation to a method:

Let d be the method in question and a tuple of <t^d,m^d>, where t^d is the static type being analyzed and m^d is the method handle. Let C(d) be the set of tuples <i^C(d)_i,t^C(d)_i,m^C(d)_i>, for i = 0 to |C(d)|, representing method calls reachable from within d’s IL body (regardless of certain code paths and/or code path probabilities—probabilistic analysis could be quite interesting, but is not the focus of this effort), where i^C(d)_i is the instance on which a method is being called (or e for static method calls), t^C(d)_i is the static type to which the method call refers, and m^C(d)_i is the method handle being called.

Let DirThrows (d) be the set of exception types for which an explicit throw instruction is present within d’s IL body.

[informative] RefThrows(d) is defined below to equal the set of exceptions that could be thrown as a result of invoking a method call inside of d’s body, transitively closed on C(d).

Let Exc(d) be the set of exception types that could by thrown as a result of invoking method d. Specifically, Exc(d) = { DirThrows(d) È RefThrows(d) | deleting any e for which d‘s body contains an enclosing exception handler that catches e or a base-type and does not issue a rethrow instruction }.

Let RefThrows(d) be union of all E_i computed as follows:

For each <i^C(d)_i,t^C(d)_i,m^C(d)_i> Î C(d)

If virtual(<t^C(d)_i,m^C(d)_i>) is false, let E_i = Exc(<t^C(d)_i,m^C(d)_i>).

Otherwise, if there exists an assignment to i^C(d)_i of type u within visibility that provides an implementation for which virtual(<u,m^C(d)_i>) is false or whose instance construction is also within visibility and that can be deterministically proven to be the last known assignment (i.e. non-pointer local variable), let E_i = Exc(<u,m^C(d)_i>).

Otherwise, let T be the set of known derivative types of t^C(d)_i. If |T| = 0, let E_i = Exc(<t^C(d)_i,m^C(d)_i>). Otherwise, let E_i = { the union of all Exc(<u,m^C(d)_i>) for each u Î T }.

I'm feeling better about this book project each time I sit down to work on it. My word count is increasing steadily, and as expected my ability to get in “the zone” and crank out pages is indeed improving. My first draft is actually about 3% complete! :P

As I'm working on my book, I'm trying to remain conscious about making it accessible to as wide an audience as possible. This obviously includes the hobbyist and student crowd. As such, I've been working with the VS Express SKUs... and I must say, they kick mucho butt!

Check 'em out here: http://lab.msdn.microsoft.com/express/

Yeah, yeah, I probably sound like some marketing swine, but so be it. I've always been a fan of lightweight programming environments (emacs, csc, and nant was my standard “ide“ until recently), and these certainly feel more lightweight than Enterprise. Shhh... I won't go so far as to say I prefer Express over Enterprise - I haven't used Express enough to make an informed judgement, and I'm sure there are a slew of nifty features that didn't make it into Express - but when you just want to whack out a bunch of code and don't need a fancy shmancy IDE that supports multiple languages, client- and web- programming together, and the like: this dogfood tastes great.

I need to set up a wiki or some other good means of capturing references and other interesting data. Bookmarks just don't cut it. In the absence of that, I'll just dump the top of my stack right here.

John McCarthy is a smart, smart man. The inventive capabilities of human beings never cease to amaze me.

• Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I
• LISP--Notes on Its Past and Future
• A Basis for Mathematical Theory of Computation
• Towards a Mathematical Science of Computation

Some Scheme papers...

• Scheme: An Interpreter for Extended Lambda Calculus [PDF]
• RABBIT: A Compiler for Scheme (Guy Steele's Masters Thesis) [PDF]
• Lambda: The Ultimate GOTO [PDF]
• More "Lambda Papers" links...

A couple other random links...

• Categories, Types, and Structures (MIT Press) [PDF]
• Structure and Interpretation of Computer Programs
• Great Works in Programming Languages

I've been searching for and have only found a few digital copies of the papers referenced in the last link. This is a great candidate for a wiki so links can easily be added as they are located...

Yep, one day Haskell and LISP will rule the world. Until then we'll just have to live with C# and its new closure-imitating syntax.

• Martin Fowler: http://martinfowler.com/bliki/Closures.html
• Jason Whittington:
• http://neocranium.com/code/archive/2004/08/07/168.aspx
• http://neocranium.com/code/archive/2004/08/07/175.aspx
• http://neocranium.com/code/archive/2004/08/11/190.aspx
• http://neocranium.com/code/archive/2004/08/24/205.aspx
• Ian Griffiths: http://www.interact-sw.co.uk/iangblog/2004/09/16/permuterate
• Joe Walnes: http://joe.truemesh.com/blog/000390.html
• Me: http://www.bluebytesoftware.com/blog/PermaLink.aspx?guid=e016964b-19b0-43ee-a804-9ff2070082c7

One of my design goals with the managed Scheme compiler is to enable easy interoperability with existing managed languages through delegate-based entrypoints. This communication needs to flow both ways, so that for example a lambda can substitute for a delegate and vice versa. My backend actually has its own representation for functions, enabling fine-grained control over scoping and such, but mutliple entrypoints are provided for this explicit purpose.

So for example,

delegate object Transform(object o);
void Map(Transform a, Array arr)
{
  //...
}

Can be called from a Schema program as follows,

((func-lkup "Map(Transform, Array)")
  (lambda (x)
    (* x 2))
  (10 15 20 25))

...and the other way around.