"Efi Merdler" <fo****@gmail.c omwrote in message
news:11******** *************@e 65g2000hsc.goog legroups.com...
Hi,
I created a user control, but instead of handling exception in the
user control level I prefer to handle them in the containing form.
In the load event of the containing form I'm using:
entryWindow.Err or += new EventHandler(Pa ge_Error);
when entryWindow is my user control.
Two questions:
1. Is this the correct way of doing that ?
2. When exception occurs I'm setting some of my controls' visibility
property to false, however it seems that asp.net ignores it and still
displays them, why ?
It looks like you are violating encapsulation. You are giving the containing
control too much knowledge of the internals of the user control. You're
asking the container to understand the exceptions thrown by the user
control. You might get away with that right now, when there's only one
possible containing control, but you should ask yourself what would happen
if you needed to use that user control in another container. Wouldn't the
other container also need that same knowledge of the user control?
Instead, why not let the user control handle its own exceptions and do with
them what needs to be done. For instance, if there's a place in the user
control where some controls are databound, and there's an exception thrown
while accessing the database, then the user control itself should perhaps
disable the controls which would have been data bound. That's not something
that a containing page should have to know about.
Personally, I never use the Error event of a page. Instead, I use try/catch
blocks, and only catch exceptions if I'm going to do something intelligent
with them. That could be something as simple as logging the exception and
displaying an error label; to adding information to the exception and
rethrowing. In rare cases, one might catch an exception that means that the
user entered data which has led to an "expected error" result. An example
might be the user entering data which would result in a database constraint
violation. In that case, I would catch the exception and turn it into a
purely UI event, possibly displaying an error message.
If the containing control is calling a method or property of the user
control, and that method or property throws an unhandled exception, _then_
the containing control should handle the exception:
string lookupKey = Request.QuerySt ring["LookupKey"];
try
{
myUserControl.L ookupKey = lookupKey;
myUserControl.D ataBind();
}
catch (DataException dEx) // Note that if it threw NullReferenceEx ception,
for instance, then global error handling would deal with it
{
lblError.Text = "No such key " + lookupKey;
lblError.Visibl e = true;
}
In any case, I suggest you keep exception handling as local as possible, and
limit it to only those exceptions you know what to do about.
--
John Saunders [MVP]
