I'm working on a page that will allow our users to view a table in a database in ASP.Net. To do this I am writing a
UserControl where I am connecting to the database through a
SqlDataSource, and I bind a
GridView on the UserControl to this datasource. If you are unfamiliar with
databinding this simply means that I hook the presenting controller (the GridView) up to an object that can provide it with data. This automagically populates the presenter with the data from the source. But, as with all automagical things can, and do, go horribly wrong.
Small digression: I'm from the
Java plains, but I've recently set up shop in the .Net woods where I mostly hang around in the soppy marshes of
ASP, the glossy banks of
MSSQL-RS and more recently the crags of
ADO. Being quite new in these parts I get to do a lot of really stupid things, and I'm building an appreciation of each land's pros and cons. One of my gripes with the marshes of ASP is the incessant focus on doing things
declaratively as the first-choice. Sure, it's great if what you want is static, but I don't want static content!
Why this rant? Declarativity just bit me in the rump, like a particularly nasty
ass.
So, I was binding my GridView to the SQLDataSource declaratively, like a good
ASP-ape. Everything was working as expected until I started testing the page with non-standard inputs. The datasource is setup with the data it needs to connect to the database, and an initial select statement to get at the data you want. If any of this is incorrect the entire page explodes in a messy way. Red goo all over the walls.
My test-case was simply setting up the datasource with an incorrect login. This caused an SQL-exception when the SQLDataSource tried to perform the initial Select (as one would expect). Now, .Net does not have checked exceptions (expect a post on this later), so being from the Java-land I am always a bit surprised and worried to see exceptions being thrown willy-nilly run-time.
Well, this exception I should be able to deal with. It is a real problem, but the application should be able to handle such problems gracefully. I just had to find some place to catch this exception, and handle it.
There are several places you can handle an error in ASP.Net:
- global.asax (where you can handle application-level errors), overriding one of the following methods
- Gobal_Error
- Application_Error
- Page_Error (where you can handle errors on a page-level)
In addition to this you can define a page to send the user to in case of an error, so the plebs don't have to see the ugly innards of your app. All of these solutions are good, but not for my use-case where I actually wanted to handle the exception, should it occur. These solutions let you do things like
log and
redirect on errors, but offer little in the way of actually handling the problem.
Yes, on a page I could have used the Page_Error, the problem is that I am building a UserControl, which is
part of a page, but not the page itself. And, a UserControl has no onError event to catch, and on Error method to override. In effect the UserControl blew up, killing all bystanding controls and page-elements.
Digging in to where the error originated I saw that it was spawned when the controls on the page where coming to life, in the
preRender -stage of the lifecycle. This tells me that I must place some code to handle this before that stage of the lifecycle to avoid this error. In the purely declarative mannar I would declare a handler for some SqlDataSource error event, but that component does not have one. So I am relegated to provoking the error myself, and handling it correctly.
This is not really all that hard, once you've gotten to this level (the realisation that I had to do it this way took much longer than the coding of the fix). What you're forced to do is to
not bind the GridView to the SQLDataSource declaratively. Read that again. To handle the error you're forced to step out of the declarative world and do the binding yourself. Now, this isn't
hard, but it suddenly seems as if the declarative way of doing things is second-rate and sunshine-days-only. I can live with that, but what I really don't like is how every example focuses on declarative implementation, when it's the less powerful and (to me) less natural way of doing things. Sigh.
Oh, well, on to the fix. Just remove the
DataSourceID="someDataSource" element from your GridView decalaration, and add something like this to you Page.Load handler:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
theGridView.DataSource = someDataSource
Try
GridView1.DataBind()
btnSave.Visible = True
lblError.Visible = False
Catch exc As SqlException
lblError.Visible = True
btnSave.Visible = False
lblError.Text = "Could not load table: " & exc.Message
End Try
End Sub
This will let the UserControl come up, even if the datasource experienced an error. Much better, but I'm left feeling it's dumb that I have to do it this way.
Technorati Tags:
asp,
usercontrol,
exceptions,
declarative,
gridview,
datasource,
error
