Devlico.Us
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @devlicious

Derik Whittaker

Thoughts on Software Development, .Net, OOP, Design Patterns and all things cool



My Initial Impressions with the new HandleErrorAttribute with MVC Preview 4

As part of my process to upgrade DimeCasts.net to preview 4 I wanted to take advantage of the new HandleErrorAttribute.  Out of the box this looked like something that I would want to use and could use very easily.  However, I quickly realized that this attribute does not cut it for me.

Why does it not work well for me, I will tell you.

  1. It is a sealed class which means that I cannot inherit and extend it.  Why would it be sealed?  Note to MVC team.  Avoid sealing classes for 'basic' features.
  2. By default it wants you to put your error page in the Views/Shared and name the page error.aspx.  Now I know there is a way to override this, but it was more painful that I had hoped.
    [MyHandleErrorAttribute(View = "~/Views/[folder]/[page].aspx")]
  3. I was not able it to route to a controller action, only to my view.  I tried to get it to route to my controller action (ok, maybe I was doing something wrong... it is possible) but did not have any luck.  Even when I could get it to display my view correctly it did not invoke the controller action for me.

All this being said, I am NOT going to switch to using this new attribute as my hand rolled one works better in my opinion and is still getting the job done (right tool for the job right :) ).

I must admit, I am a bit sad that this nice, common feature did not work out for me.

If anyone else has had better luck with this please let me know.

Till next time,

[----- Remember to check out DimeCasts.Net -----]



Comments

Derik Whittaker said:

@El Guapo,

You may in fact be correct.  However, that is a pretty lame reason.  The people that are willing to use and extend the MVC are the ones that are willing to perform rework for future releases.

# July 27, 2008 8:26 PM

Matt Dunn said:

Apparently there is a significant performance boost for reflection in resolving sealed vs unsealed attributes. Most of the attributes in the .NET framework are sealed presumably for this reason (its also recommended in the Framework Design Guidelines).

This doesn't make your comments any less valid though :)

# July 27, 2008 8:40 PM

ASP.NET MVC Archived Blog Posts, Page 1 said:

Pingback from  ASP.NET MVC Archived Blog Posts, Page 1

# July 27, 2008 9:48 PM

Derik Whittaker said:

@Matt,

Wow, i would have never thought about the reflection angle.  Would like to see some data behind that (not that I do not believe you) to see what type of gains making something sealed is.

# July 27, 2008 9:51 PM

Christopher Steen said:

Link Listing - July 27, 2008

# July 28, 2008 6:14 AM

Ben Scheirman said:

Who gives a flip about reflection performance when you're throwing a freaking exception?

Seriously, in an error state, which will seldom happen (hopefully) who really cares about saving a few CPU cycles.

I ran into this same roadblock with the [Authorize] attribute.  I sent an email to the team.

# July 28, 2008 2:00 PM

Haacked said:

Regarding putting your Error.aspx in the Views/Shared folder. Keep in mind that we use the normal view location mechanism for finding the view.

Without changing your attribute declaration, you can simply add a controller specific error.aspx into the corresponding directory.

/Views/ControllerName/Error.aspx

And it will resolve that one instead. No need to do this:

[MyHandleErrorAttribute(View = "~/Views/[folder]/[page].aspx")]

# July 28, 2008 4:10 PM

ScottGu said:

I just a checkin that unsealed the filter attributes - this will show up in the next MVC drop.

Hope this helps,

Scott

# July 31, 2008 7:22 PM

Derik Whittaker said:

@Scott,

That s great.

Thanks,

# August 5, 2008 6:43 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Derik Whittaker

Derik is a .Net Developer/Architect specializing in WinForms working out the northern suburbs of Chicago. He is also believer and advocate for Agile development including SCRUM, TDD, CI, etc.

When Derik is not writing code he can be found spending time with his wife and young son, climbing on his bouldering wall, watching sports (mostly baseball), and generally vegging out. Check out Devlicio.us!

Our Sponsors

Proudly Partnered With


This Blog

Syndication

News