views:

39

answers:

2

"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

A: 

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.

Alex Humphrey
A: 

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.

Kieren Johnstone
It depends what exceptions are being thrown. The default error page is designed to handle 'big' failures, like 'cannot connect to database'. When this happens, there are no guarantees that anything is going to work, so the best thing to do is go to the default error page. If the errors are because 'the string won't fit in that field' its a validation problem and a coding error - you should never even have tried to get that string into that field - you should have checked that it would fit, and if it didn't, tell the user via the label mechanism.
Alex Humphrey