Calling Page properties from a class

[token]

I have this error handler class, and I was wanted to be able to change page the user is looking at from the class rather than having to return to the class to change the page.

As an example: the form would call a method in another class, if an error occurred in the method of that class it would call the error handler that would log and email the error and I would like it to redirect the user to a generic error page. This way I dont have to keeping throwing back so the original caller would have to deal with the error, the error would be dealt with and would have already informed the user.

I hope I'm making sense.

Anybody have any ideas.

[nemaroller]

Pass in the HttpContext.Current


//C#
public static void DoSomething(System.Web.HttpContext context)
{
int r = 9, t= 0;
float f = 0;
try
{
f = r / t;
}
catch (System.DivideByZeroException)
{
context.Response.Redirect("http://www.google.com");
}
}

Then, you call it like so:

MyErrorHandler.DoSomething(HttpContext.Current);

[token]

That's a great idea. Thanks I will give that a try. I appreciate the response.

[token]

Beauty, worked like a charm. Thanks again.

[token]

Just a question. Would it be possible maybe to pass the context in a different manner than as a parameter?

The problem is that I dont really want to change the signature of all the methods in all my classes so that if there is an error it can pass the context to the errorhandler.

Is there some sort of session variable or application variable that I can use to set at page_load and then can refer to in the error handler class when needed.

[nemaroller]

Well, a class has only the ability to work with what you provide to it.

Your errorhandler class will only be able to access Session if it has a context to operate in - hence the passing of the httpcontext that I demonstrated.

The typical webform in a asp.net application derives from System.Web.UI.Page. The Page class has as a property an HttpContext - which is the context associated with the current request (request for info from a browser client).

So in a webform (page class), .Net already provides you with the context. So you can easily access Session, Application, the user agent string, etc. Every request is a different context (.Net instantiates an instance of the page class when a request is made, does some processing, then destroys the instance - because the request has been served, and no doubt the next request will be somewhat different).

To bring this functionality into a regular class -you need to do the same thing the framework does, by making the current httpcontext available to the class. Whether you set a property, pass it in through the constructor, or pass it as a parameter to a method - somehow that information needs to get there.

To me - your situation could probably be easily solved by implementing Application_Error in the global asax. In there, you could easily pass the context:

private void Application_Error()
{
RasErrorHandler.HandleError(HttpContext.Current);
}


The RasErrorHandler class would implement a static method HandleError that accepts a HttpContext, fires off an email, then does a Response.Redirect to your generic error page.

[token]

Thank you very much for all that. I understand what you are saying and I will give that a try.

Though just a question, though it may sound stupid. The classes that are outside the actual web project, will they be able to access the Global.asax for the web project?

Or will I just have to throw back, to the webproject that called the class method, the exception when an error occurs outside the web project.

[nemaroller]

Ok... so it sounds like you have a solution with at least two projects, one is the web app, and one is a class library, correct?

If an error occurs within the web app, the global asax obviously will call your errorHandler (in your class library), passing it the current HttpContext, to which your errorHandler will be able to retrieve the last server error, so forth.

If an error occurs within your class library, well that really depends on what information you want to display to the client. Obviously, if an error occurs, you would have to think how you want to handle that - because its really not a web app error, its a class error, which should be either eaten or bubbled up.