tags:

views:

29

answers:

1

hello all,

I'm almost embarrassed to ask this question, but here goes. Yesterday I was testing an application that's due to go into production in a few weeks time when an unusual error was triggered by one of my collegues. Basically, she pulled the database connection whilst the view was iterating round an IQueryable collection (inside a partialview). Now, the controller responsible for this has error traps in place and I expected this to kick in with a warning. However, what basically happened was that the yellow .net error page kicked in showing the line where the error occurred. Now, luckily this is still in test, so we can make the neccessary changes to fix this and also, it's a real edge case so this type of error may never occur.

However, does anyone have a solution to catching such an error and presenting a sensible 404 page in this event?? Or is there something in the controller that is perhaps being overlooked in our defensive programming and try/catch blocks??

hope someone has crossed this bridge before and exited with flair...

A: 

If I focus only on error and page not found handling there are some great questions on SO about 404 handling but in your case this shouldn't be 404, it is 500 - doesn't really matter that much but you should still diferentiate those two. For each of those two you can make a pretty custom error page.

I've followed the answer from cottsak in this SO question and the corrections made by other users/commenters in that same question. It is a better solution than the accepted answer, I think.

However, it might be that you are handling something that should never happen. What do you mean by "she pulled the database connection"? It could mean that your site is not set up correctly to handle multiple user requests. I would recommend "per request" database connection / database context scopes in ASP.NET MVC applications.

mare
hi mare. by 'pulling the connection' i mean that she literally took the database offline from sql admin. this was intentional but threw the error that we didn't expect. i'll take a look at that cottsak question just now. our db connections are serviced via subsonic 3 talking to sqlserver and is setup as you alude to - i.e. 'per request'
jim