Display ASP .NET Error in JavaScript Alert Window.

[jehugaleahsa]

Hello:

I am going through an effort to standardize web applications for my
company. We are trying to figure out the best practices for security,
error handling, etc. I've just done a large amount of work to figure
out the built-in ASP .NET security features (which was fairly easy to
do). So now I am tackling error handling.

What we would like to do is show a JavaScript Alert box with the error
information in it. Here is the code I wished worked (but it doesn't):

protected void DetailsObjectDataSource_Modified(object sender,
ObjectDataSourceStatusEventArgs e)
{
if (e.Exception != null)
{
StringBuilder builder = new StringBuilder();
Exception exception = e.Exception;
while (exception != null)
{
builder.Insert(0, Environment.NewLine);
builder.Insert(0, exception.Message);
exception = exception.InnerException;
}
ScriptManager.RegisterClientScriptBlock(this,
this.GetType(),
"DetailsUpdate",
"Alert('The following error occurred: " +
builder.ToString() + "');",
true);
e.ExceptionHandled = true;
}
OverViewGridView.DataBind();
}

How can I relay a message to the user via an Alert box?

Another question: We have issues with data here such that our
DropDownLists are regularly throwing exceptions. What is the best way
to indicate to a user that a value in a drop down list is invalid and
*must* be changed? How do you prevent the DDL from throwing an
exception? or how do you prevent it from killing the application?

[Scott Roberts]

<je**********@gmail.comwrote in message
news:e2**********************************@s8g2000p rg.googlegroups.com...

Hello:

I am going through an effort to standardize web applications for my
company. We are trying to figure out the best practices for security,
error handling, etc. I've just done a large amount of work to figure
out the built-in ASP .NET security features (which was fairly easy to
do). So now I am tackling error handling.

What we would like to do is show a JavaScript Alert box with the error
information in it. Here is the code I wished worked (but it doesn't):

protected void DetailsObjectDataSource_Modified(object sender,
ObjectDataSourceStatusEventArgs e)
{
if (e.Exception != null)
{
StringBuilder builder = new StringBuilder();
Exception exception = e.Exception;
while (exception != null)
{
builder.Insert(0, Environment.NewLine);
builder.Insert(0, exception.Message);
exception = exception.InnerException;
}
ScriptManager.RegisterClientScriptBlock(this,
this.GetType(),
"DetailsUpdate",
"Alert('The following error occurred: " +
builder.ToString() + "');",
true);
e.ExceptionHandled = true;
}
OverViewGridView.DataBind();
}

How can I relay a message to the user via an Alert box?

Try RegisterStartupScript instead of RegisterClientScriptBlock.

Another question: We have issues with data here such that our
DropDownLists are regularly throwing exceptions. What is the best way
to indicate to a user that a value in a drop down list is invalid and
*must* be changed? How do you prevent the DDL from throwing an
exception? or how do you prevent it from killing the application?

You have to catch the exception when the SelectedIndex or SelectedValue of
the DDL is set. I'm not sure how to do this if you're using data-bound
controls (we don't use databound controls). What is the default value of the
DDL for new items? I'd set it to that.

Obviously you'll want to figure out where all this bad data is coming from
and correct that as well. :)

[jehugaleahsa]

Try RegisterStartupScript instead of RegisterClientScriptBlock.

That got it!

>

Another question: We have issues with data here such that our
DropDownLists are regularly throwing exceptions. What is the best way
to indicate to a user that a value in a drop down list is invalid and
*must* be changed? How do you prevent the DDL from throwing an
exception? or how do you prevent it from killing the application?

This is mostly an issue because our DBAs are rather slow when it comes
to correcting data. In most cases, they call the user and have them
specify what the value *should* be. It would be much easier to allow
the user to do this directly, rather than go through the 15-20 minute
rigamarole. I suppose it would be less frustrating if our DBAs learned
to identify these errors instead of needing our participation -
wishful thinking.

>
You have to catch the exception when the SelectedIndex or SelectedValue of
the DDL is set. I'm not sure how to do this if you're using data-bound
controls (we don't use databound controls). What is the default value of the
DDL for new items? I'd set it to that.

We are extremely dependent on data binding. We have had bad
experiences with manual binding and tend to avoid it. The DDL for
ASP .NET lacks many useful features, but that is a limitation from
HTML. For instance, you cannot add a new value to the list directly.
Instead, you have to modify the data source and rebind. The
SelectedIndexChanged event is "too late" since it takes place after
binding is completed (or after the error has already occurred). My
idea is to have a check occur when the business object with the
selected value is first queried. It would do the check first - if it
fails it could redirect the user to a screen where they can chose a
meaningful value. However, the details seem too complicated to do
generically.

>
Obviously you'll want to figure out where all this bad data is coming from
and correct that as well. :)- Hide quoted text -

Oh, we do. We have newer systems that are upgrades from Oracle Forms.
The old systems had poor validation and on occasion these old mistakes
crop up. Additionally, data is often imported in-mass from outside
sources which may or may not adhere to the new system's requirements
(or our DBAs screw up something horrible).

Thank you for your help. It will definitely come in handy.

[Scott Roberts]

>You have to catch the exception when the SelectedIndex or SelectedValue
of
the DDL is set. I'm not sure how to do this if you're using data-bound
controls (we don't use databound controls). What is the default value of
the
DDL for new items? I'd set it to that.

We are extremely dependent on data binding. We have had bad
experiences with manual binding and tend to avoid it.

I've had exactly the opposite experience! Regardless......

The DDL for
ASP .NET lacks many useful features, but that is a limitation from
HTML. For instance, you cannot add a new value to the list directly.
Instead, you have to modify the data source and rebind.

I believe that you can add "static" items then set the
"AppendDataBoundItems" property to True. Careful though, the DDL will not
automatically clear items when you rebind if you do this. You'll need to
handle situations where you re-bind DDLs carefully.

The
SelectedIndexChanged event is "too late" since it takes place after
binding is completed (or after the error has already occurred). My
idea is to have a check occur when the business object with the
selected value is first queried. It would do the check first - if it
fails it could redirect the user to a screen where they can chose a
meaningful value. However, the details seem too complicated to do
generically.

Indeed. If you have a business object then all validation should occur there
anyway. Obviously DB constraints would be best, if possible. If anyone says
"But that will break application XYZ!" you can simply respond "Application
XYZ is already broken, it's just not generating exceptions when it breaks!".
:)

[jehugaleahsa]

On Dec 26, 1:43*pm, "Scott Roberts" <[e-mail]-webworks-
software.comwrote:

You have to catch the exception when the SelectedIndex or SelectedValue
of
the DDL is set. I'm not sure how to do this if you're using data-bound
controls (we don't use databound controls). What is the default value of
the
DDL for new items? I'd set it to that.

We are extremely dependent on data binding. We have had bad
experiences with manual binding and tend to avoid it.

I've had exactly the opposite experience! Regardless......

The DDL for
ASP .NET lacks many useful features, but that is a limitation from
HTML. For instance, you cannot add a new value to the list directly.
Instead, you have to modify the data source and rebind.

I believe that you can add "static" items then set the
"AppendDataBoundItems" property to True. Careful though, the DDL will not
automatically clear items when you rebind if you do this. You'll need to
handle situations where you re-bind DDLs carefully.

The only static item we could make would be a blank or "null" field.
We have many instances where "null" is not allowed, so that eliminates
that option. Currently, the application just explodes and we are sent
a message about where to find the bad data. The real problem is that
ASP .NET will attempt to validate each record returned by an
ObjectDataSource. So, if we have a FormView with a validated
DropDownList in it, we may get an error even if the current record is
fine. Somewhere in the results there is a bad record (and there could
be hundreds of records). We can only conclude that the bad record
belongs to a parent record, but not know the pin-point location. We
some times have to search carefully for the record that is in error -
it would be nice to get the bad record directly.

Perhaps I should simply search through my records and remove bad
records prior to releasing them to the interface. Then for each bad
record I can send an email to our DBAs. At least this way our users
don't experience bad data. I could indicate to them that some records
have been excluded and they have to contact the DBA to retrieve them.

>

The
SelectedIndexChanged event is "too late" since it takes place after
binding is completed (or after the error has already occurred). My
idea is to have a check occur when the business object with the
selected value is first queried. It would do the check first - if it
fails it could redirect the user to a screen where they can chose a
meaningful value. However, the details seem too complicated to do
generically.

Indeed. If you have a business object then all validation should occur there
anyway. Obviously DB constraints would be best, if possible. If anyone says
"But that will break application XYZ!" you can simply respond "Application
XYZ is already broken, it's just not generating exceptions when it breaks!".
:)

DB constraints here are rare and far between. Our databases are
ancient and lack some basics like foreign key constraints. We could
add them anytime, but for some reason we don't. I would hate to step
on someone's toes. :-\

Thanks, you got my wheels turning,
Travis