0

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...

jim tollan
  • 22,305
  • 4
  • 49
  • 63
  • So your model is strongly typed to an IQuerable<>? And it gets executed on the view? – Martin Sep 09 '10 at 13:26
  • Martin, yes that's exactly the scenario – jim tollan Sep 09 '10 at 18:19
  • Then why not exceute the model in the controller and catch any errors there, then pass an IEnumerable<> or IList<> to the model? – Martin Sep 10 '10 at 12:15
  • martin, that could well be an option altho' we have literally 100's of views and partials (well, about 120 odd) that are using IQuerable across the board. but your suggestion does make sense insofar as trapping the error at source. i've got a feeling that the nature of arrival at this scenario may well not warrent too much thought, given that it was a deliberate 'pull' that occurred during a 'known' moment inside the view. good theoretical stuff mind you.. – jim tollan Sep 10 '10 at 13:03

1 Answers1

0

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.

Community
  • 1
  • 1
mare
  • 13,033
  • 24
  • 102
  • 191
  • 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 tollan Sep 09 '10 at 11:35