OK to throw an error for a missing required querystring parameter?

Is there anything wrong with having an asp.net page throw a (custom error) if a a required querystring parameter is missing and having global.asax catch it with Application_Error, then transfer the user to an error page? I have several base classes that perform these checks and I am not sure of the best way to communicate the error to a user.

So, something like this:

int reqParam;
if(!isParamSet("myReqParam", out reqParam))
{
   throw new QuerystringParamMissingException();
}

whic开发者_运维技巧h is then caught by Application_Error in global.asax.

Also, from a security standpoint how much information should I be providing to the user? Just that it was an error, or that a querystring parameter was missing, or which parameter was missing, or maybe even what that parameter indicates is used for?

It all depends on how serious an error it is and whether the user can easily recover from the error.

One view is that the user shouldn't be able to make invalid calls - all links that require query strings should be validated client side, so during the normal operation of the site all query stings will be complete and valid. Therefore it would be a serious error if there were parameters missing, so raising an exception is a perfectly valid approach.

It would be useful if you want to stop people modifying the query string to gain access to parts of your system they shouldn't. They're likely to miss off a parameter and displaying a custom error page might not give them any clues about what they got wrong.

You should log the error though - so at least you know what when wrong and where.

So long as you don't believe this situation should arise in normal application usage this is an acceptable solution.

What you do by letting the Exception bubble up the stack is destory any chance of recovering from the error, in this case you may not be able to recover anyway.

I believe you should not let your application throw an error as long as you can control the situation. I mean since you know what a parameter could be missing...so you could prompt the user for that instead of throwing an error and then letting the application handle the rest of the case.

Instead provide a user friendly message and help the user understand what went wrong!

Thanks, Take care.

You should log this error that was (you have to be sure) caused from user manually manipulating the query string and then redirect to a default page(home or login-page). When the missing parameter is caused by your application f.e. not full validating user input, then you should eliminate the cause.

Just remember that there's a performance cost to throwing exceptions. It's a lot more performant to just page redirect to the error page & handle the error without throwing an exception.

That being said, it is rather convenient to just throw an exception, since there's a lot of configurable as well as built-in mechanisms in ASP.NET for dealing with exceptions, for instance:

HttpContext.Error
HttpContext.AllErrors
HttpContext.IsCustomErrorEnabled
<customErrors defaultRedirect="..."> node in the web.config