In the last post in the series, I moved the error handling aspect into an opinionated one by using Exceptionless and handling certain types of exceptions (like SqlException and NotImplementedException).

In this post, I'm going to go even further down the opinionated road and talk about exception recovery.

My goal is for any exception to be caught and logged, and we're already there. In addition, I'd like the user not to see a yellow screen, so I'm generally not allowing the exception to bubble up, in lieu of a nice error message being put into ModelState (or some other error handling). However, this might not be enough. If the service method throwing an exception has a return value, then it's likely that another error will happen later in execution (maybe due to a null reference). For example:

If the method doesn't throw an exception, everything is fine. If it does throw an exception, there will a null reference when I attempt to use the Count property. What I would prefer is that an empty collection is returned. In fact, this fits with the recommendations from Framework Design Guidelines (page 256) to always return an empty collection (or array) instead of null. I've added a helper method to construct the return value in case this occurs.

What about if the service method is not returning a collection? And what if it's returning a value (like int or DateTime)? It's okay to return a null in the first case. In the second case, it might be okay to throw an exception. I have so few of these in the project I'm working on that I don't worry about it much, but for the sake of completeness, let's just make it return the default value.

I need to be very cautious about what I'm doing, and wrap everything in a try/catch so that I don't end up causing another unhandled exception in my exception handling code. It would be a good idea to create some unit tests to make sure everything is behaving as expected.

Okay, I think one or two more posts will wrap it up for this series. We need to discuss whether or not the exception message should be shown to a user (hopefully you're leaning towards "no").

• This only works for ITerritoryService
• Swallowing exceptions: we should at least be logging the exception, not just ignoring it.
• If the method has a return type, then it's returning null. If it's meant to return a reference type, that's probably fine, but what if it's returning a value type?
• What if it's returning a collection, and the UI assumes that it will get an empty collection instead of a null reference?
• Do we really want to return the exception message to the user?
• What if I forget to use ServiceBase as a base class on a new service?
• Unit tests: how to test this aspect in isolation.

The Boise .NET User Group was kind enough to invite me to be a presenter. Boise is a bit too far away for me to make it there on a weekday on a small budget, but they were accomodating enough to allow me to present remotely. There were a couple minor technical issues, but mostly it went well. Even though I've done this presentation a lot, Brian cajoled me into talking about INotifyPropertyChanged, which is something I've only done once before during this talk (usually I'm constrained for time, or the group isn't interested in the MVVM pattern).

Brian Lagunas even made a recording of the presentation. The recording started a minute or so late, and it ending a couple minutes too early (the internet in the Boise location went down), but most of it is was recorded with Microsoft Live Meeting (not my favorite remote collaboration tool, but it was adequate). And now, it's on YouTube:

Slides and code are available in the AOP For You and Me GitHub repository.

Based on a Twitter conversation with Seth Petry-Johnson about mocking/faking SqlException objects in .NET, I decided to go ahead and put what I had written into an open-source project on GitHub. I didn't spend much time on the name: I thought about Sharp Stick and Pointy Stick, but those repo names have already been taken! So, I thought about "stick" some more and remembered the famous line from Lady Macbeth: "screw your courage to the sticking place". Well, I guess I don't have much of a future in professional naming.

Since I was creating a repo anyway, I thought I'd throw a couple of other helpers in there. I put in some of my favorite ASP.NET / ASP.NET MVC helpers and an obscure little string helper. I'm not trying to remake PGK Extensions or anything--just putting some stuff out there that might help someone.

I should also note that the SqlExceptionHelper stuff isn't entirely original: I borrowed some code from a 2006 blog post by Rido, and just updated the reflection code since the private constructor has changed since then (and could possibly change again, since it's a private constructor in a sealed class).

Anyway, go check out Sticking Place on GitHub and let me know what you think.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• Commit to Github or other public git repos without sharing your private information (like API keys and passwords and such)
• ReSharper and Roslyn would seem to go together like a lime and a coconut, but it seems that's not in JetBrains's immediate plans.
• However, DevExpress claims to be all-in with CodeRush and Roslyn. I don't know if these points of differentiation makes any difference right now, but could be interesting in, say, 6 months to a year from now.
• I was able to see Gary Bernhardt's session "The Birth & Death of JavaScript" at CodeMash this year, which is now available as a video on Destroy All Software. It might seem like a satire at first, but it's actually a really deep, layered, and meaningful talk that should be of interest to everyone, not just JavaScript or web developers.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

StructureMap 3 was released recently, and as a regular user of StructureMap, so far I have to say that I'm pleased.

Mainly because not much was really broken, and also because I'm just happy to see a project I use so much continue to get updated.

There are a couple things that are moved around or renamed. In this post, I'll be talking about HTTP request scoping, decoration, and assembly scanning.

HTTP Request Scoping

StructureMap 3 no longer includes anything tied to HttpContext. But don't panic! It's all been moved to another package: StructureMap.Web. The API is a little different as well. Compare and contrast:

Also note that the cleanup (which I typically put in Application_EndRequest in Global.asax.cs) is also a bit different. In StructureMap 2, I would just call ObjectFactory.ReleaseAndDisposeAllHttpScopedObjects();. In StructureMap 3, instead I call HttpContextLifecycle.DisposeAndClearAll();.

Decoration

If you are using the decorator pattern, then you probably often wire it up in your IoC container. In StructureMap 2, you used EnrichWith. In StructureMap 3, you use DecorateWith. I also think, but I'm not 100% sure, that DecorateWith is a little smarter about types as well. which I only noticed in some of my Castle DynamicProxy stuff. Behold:

If you have my book, AOP in .NET, then you'll know that a change to "EnrichWith" is fairly significant to the code examples in that book. But luckily, it's a relatively easy change (or you can just keep using StructureMap 2.x).

Assembly Scanning

Not a big deal here, just note that some of the assembly scanning extensions (specifically TheCallingAssembly, AssembliesFromApplicationBaseDirectory, AssebliesFromPath) have moved to the StructureMap.Graph namespace. No biggy, especially since ReSharper is able to point these things out and add "using StructureMap.Graph" automatically.

Summary

StructureMap 3 is definitely worth a shot. Based on the NuGet numbers so far, it's not being installed en masse just yet. But based on how I use StructureMap, it's practically a no-brainer to make the upgrade. One thing I didn't mention above (because it's not an API change) is that the error messages in StructureMap are now way more useful, and there are other benefits (like performance) that you are essentially getting for free (in terms of the time you'll spend upgrading). The only drawback is that documentation (as always) is lagging, but between the unit tests, Stack Overflow, and just noodling around, I haven't found that to be much of an impediment to an otherwise splendid tool.