how to handle all sql exceptions throughout the page [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 12 years ago.

"I DONOT WANT TO use the default error page tachnique, because i donot want the webpage to redirect!"

yes there is the try and catch

yes there are way to add exception handling mathods overwrite for controls

but what i need is,

it may just be a simple sql command,it may be a control such as formview, it may be a control such as datagrid, whatever it may be, when an illegal entry is done into the table of the database,

"THE BIG ERROR PAGE SHOULD NOT COME!!"

instead

a label at the top of the same page (where the illegal operation is performed) should display the error like

"error caused by "this control" and the error message is "null is not allowed 开发者_如何转开发in this field blah blah"

thank you

note:- am i asking for the complete code! well yes please guide me thanks

---

I think the bottom line is that you need to validate your data before you try to put it in your database.

Each control contains its own validation hooks. Check the documentation for the controls you are using on MSDN in order to find out how to properly validate the data contained in them. In your validation procedure you can then determine the controls containing the bad data and update your label.

The default error page is not an error handling technique as such. It is a failsafe for when your application fails. Your updates to the database are throwing boneheaded exceptions - exceptions which your code should never cause to happen - you shouldn't even handle them - they represent bugs in your code which need to be fixed.

Simply grabbing plain user input without validating, trying to get it into your database, and then trying to detect problems is a recipe for disaster. I hope that you're at least wrapping your database commands in transactions if you're doing this, otherwise you could end up with who knows what in your database.

---

Use a try and catch construct around your SQL queries: if the code in the catch block is hit, then call a method which makes your error label visible, and sets some error text relevant to the part of the code that failed.

This is the cleanest and most widely-accepted way of dealing with this; although you should have separation and encapsulation too. The user interface (ASP.NET pagebehind code, for example) shouldn't usually call straight through to a database; it would call business logic methods or Data Access Layer methods which would update the database. You'd still want to catch exceptions that are thrown from these layers, though. The 'best' you can do is to create a method that manages the state of your 'error' label.

Hope that helps.