NDepend on a Real Project, Round 1.3: An Exception by Any Other Name...

This is the third in a series of blogs looking at things NDepend told me about a personal project of mine. The previous posts are:

The third of the Critical Rule Violations I looked at was a class derived from Exception which didn't have a name which ended with 'Exception'. I'm pretty strong on conventions, so it surprised me to see that one. Let's see which one it was:

NDepend Exception naming report

Hmm – the UnconvertibleConfiguredValueException – that looks like it ends with the word 'Exception' to me. Clicking into the class:

UnconvertibleConfiguredValueException

Ahh, ok – it has generic parameters. If you look again at NDepend's Linq query to see how it's deciding what type names end with 'Exception', it's using a NameLike() method to check the name of each type. Awesomely, if you mouse over NameLike in the query, you get documentation, like this:

NameLike documentation

...so out of the box it's checking type names against the regular expressions 'Exception$' and 'ExceptionBase$' – so anything ending in 'Exception' or 'ExceptionBase'. Generic type names are suffixed with a backtick and the number of type parameters they take (like this), so UnconvertibleConfiguredValueException would be named UnconvertibleConfiguredValueException`2, which explains is why it comes up on the report. I can edit the query to accommodate this:

NDepend Exception query edit 1

So there we go, I've added another condition – don't match Exception types which have a name ending in 'Exception', followed by a back tick, followed by one or more digits. Hang on, it hasn't worked – NDepend recompiles and re-runs the query as you edit, and UnconvertibleConfiguredValueException is still in the report. Ok, let's edit it again to see what NDepend is getting for the type name:

NDepend Exception query edit 2

...ahh, there we go – it uses a friendly version of the name. Ok then, I can change my regular expression like this:

NDepend Exception query edit 3

...and success! We're now ignoring anything which ends with 'Exception' followed by an open angle bracket, followed by one or more occurrences of anything but a close angle bracket, followed by a close angle bracket.

I think this little sequence shows off one of the strengths of NDepend, which is how easy it is to tailor it to your project if need be. It's perfectly intuitive, has intellisense, extensive built-in documentation, and a reactive and helpful editor. Here's what it looked like as I was editing the query:

NDepend query editor error

...the feedback on the query result and syntax is instant, and doesn't interfere with your typing at all. Excellent stuff :)

Next time I'll turn to rather a more complicated issue – namespaces with circular references to each other.

Print | posted @ Saturday, December 14, 2013 5:20 PM

Comments on this entry:

Gravatar # re: NDepend on a Real Project, Round 1.3: An Exception by Any Other Name...
by Patrick Smacchia at 8/1/2014 5:12 PM

FYI, based on your feedback we modified the default Exception naming rule to take account generic Exception type. This is now delivered in the version 5.4.0 just released today.

// <Name>Exception class name should be suffixed with 'Exception'</Name>
warnif count > 0 from t in Application.Types where
t.IsExceptionClass &&
// We use SimpleName, because in case of generic Exception type
// SimpleName suppresses the generic suffix (like <T>).
!t.SimpleNameLike (@"Exception$") &&
!t.SimpleNameLike (@"ExceptionBase$") // Allow the second suffix Base
// for base exception classes.
select new { t, t.SimpleName }

// The name of an exception class should end with 'Exception'.
Post A Comment
Title:
Name:
Email:
Comment:
Verification: