Easier debugging thanks to lightweight methods


On this blog I had the opportunity to discuss about the advantages in respecting basic Code Metrics thresholds, such as having a method with low numbers of Lines of Code, low Cyclomatic Complexity, low Nesting Depth, low number of parameters, low number of variables etc…

But while doing intensive debugging today, I just realized another advantage in having lightweight methods: When a client reports a stack trace, with a typical let’s say NullReferenceException, having a lightweight method that throw such exception de-facto limits the number of potential culprits references in the method. Ideally I can know exactly which reference in the method was null at run-time and provoked the exception. Btw, it is also efficient to investigate in the set of methods callers from the stack trace, to assert which reference weren’t null at runtime and limit he number of culprits.

If only .NET had non-nullable references types, our developer job would be soooooooo much easier! Maybe it is worth writing a blog post named I want non-nullable types in C#5 ???


This entry was posted in lightweight methods. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://asimilatorul.com/ Eduard

    Sorry for being off-topic, but I didn’t found any other way of contacting you.

    The sample code for Practical .NET2 and C#2 is still available somewhere? http://www.practicaldot.net seems to be abandoned.

    Thank you,

  • http://judahgabriel.blogspot.com Judah Himango


    Off-topic, but the email you sent out for a free NDepend license is a wonderful offer. Unfortunately, replying to your email twice now, and your server bounces back by email.

  • http://judahgabriel.blogspot.com Judah Himango

    Patrick, keep pushing for non-null reference types. You’re a visible voice in the .NET world. Keep asking, and you will receive. :-)

    Let’s see a I want non-nullable reference types in C# 5 post.

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    Kim, I had the chance to talk with Anders while C#2 was still on the track, and at that time he was completely reluctant to non-nullable ref types.

    Its main reason was that a lot of C# code was already written including the .NET fx v1.1 (in 2005!), and non-nullable ref types would have been so prevalent, that it would have provoked a lot of refactoring.

    I really did my best to convince him that in 2005 .NET was still at the inception and that it wasn’t too late, but unfortunately, it didn’t worked :( This could have impacted the whole .NET development paradigm.

  • Kim

    I think Anders Hejlsberg commented on PDC’08 that lack of implementing non-null reference types in C#/.NET 1.0 was one of his bigger regrets. He didn’t see a good way of implementing it, aside from the Code Contract version, without getting issues with backwards and cross language compatibility.

    Personally I would prefer a language specific implementation over no implementation.

  • fschwiet

    The particular error, derefencing null, was used as an example. The point applies to any runtime exception, so I do not think prescribing F# or code constraints to eliminate one class of runtime error is besides the point.

    Code contracts are just meh anyhow. Unit tests that verify what your code does are better then a bunch of bloat that tries to verify what your code doesn’t do.

  • Kaveh Shahbazian

    F# which is 2.0 is pretty mature by now AND the important thing is: IT IS A .NET LANGUAGE! So – as for sure you know it better than me – there is no need for any exotic-acrobatic changes here: everything can grow granular toward a rational state in a specific context at a specific time (change is inevitable). A big enough part of LOGIC can be handled by F# and those parts with most “imperative” nature can remain in other languages and meat and bread is: interoperability! :)

  • http://www.kopis.de Carsten

    Right today I stumbled upon a method that had one huge try-catch, and I needed to mock all of the things for my unit test. I wasn’t even sure there was ONE way to get through it without throwing an exception, but finally I managed to get the unit test running – and figured out that there was a case where a LDAP directory context wasn’t closed, because (somewhat unnecessary) throwing an exception prevented a nice cleanup. But as the whole class file was < 1k lines, I won’t complain… :-}

    When I need to add or rewrite parts of the code, I’ll definitly have lightweight methods that do only one thing at a time.

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    >just go for F# –

    ‘Just’?! do you mean ‘just’ update the 100.000 physical lines of code we are responsible for? why didn’t I think of F# before :)

    >What about non null constraint and code contracts?

    The post was more about lightweight methods making it easy to debug from a stacktrace.

    But concerning null constraint and code contract (we use them extensively) by definition a bug is a code contract broken. If non-nullable types would be supported, it would be a much more efficient syntactic way to declare non-null code contracts, so much better actually than what we have now, that NullReferenceException would almost become a bad memory from the past.

  • Carsten

    just go for F# – there this (non-nullable user-types) is the default 😉

  • Kim

    What about non null constraint and code contracts?