Does HealthMonitoring have a built-in event that catches 404 errors? I have tried setting up all events (by using webBaseEvent) and I've searched for two days, but I cannot find or trigger an event for a file not found.
I could create my own, but was hoping there was a built in event.
No, it doesn't. You'd have to create a custom event (from webrequesterrorevent) to have HM track it for you.
How to:
Something like this (from memory) in Application_Error in global.asax -
public void Application_Error()
{
var exception = Server.GetLastError() as HttpException;
if (exception != null && exception.GetHttpCode() == 404)
{
//custom error
new Http404Event(this, exception).Raise();
}
}
Related
I have a gridview that is bound to a entitydatasource.I've creaetd this using drag and drop from the asp.net controls in the toolbox, and using an entity data model.I have had little input in the codebehind. For testing purposes I have edited the gridview and added data that is invalid. I've then clicked update to cause an exception.
So my question is I would like to try and catch the exception in my own error handler but I don't know where or how I can do this as I'm not sure which event I should be focusing on. I would just like to know where to begin with this.
Many thanks
You can trap the exception in the OnUpdated event of the EntityDataSource:
protected void EntityDataSource1_OnUpdated(object sender, EntityDataSourceChangedEventArgs e)
{
if (e.Exception != null)
{
// handle here
e.ExceptionHandled = true;
}
}
}
you won't able to given the form was designed using drag'n drop, declarative syntax. You are better off validating the user input before submitting it to the server. This should catch most exceptions.
your other option is to replace the declarative markup with code in the code behind where you can catch exceptions or call validation prior to calling SaveChanges();
you can catch the exception in global.asax but it will show generic error.
The goal is to intercept when user code calls Response.Redirect and alter the URL the browser is being redirected to. To alter this URL, I need access to Session (stored in Session is information that tells me what I should put in this URL.) Mostly I'm just appending a query argument to the redirect location under a circumstance.
PreSendRequestHeaders does let me alter Response.RedirectLocation. That's fine. However, I'm unable to access Session state from here. It's apparently been released before this event is fired.
So, I need a way to get this information into PreSendRequestHeaders; or I need another way to accomplish this. Ultimately my goal is to just append an argument to the query string of wherever the browser is being redirected.
If you can modify the code that writes to Session then you can use Context.Items.
For example, before the Response.RedirectPermanent method existed, I used the following:
//in some library
public static void PermanentRedirect(this HttpContext context, string url)
{
context.Items["IsPermanentRedirect"] = true;
context.Response.Redirect(url);
}
//in global.asax
void Application_PreSendRequestHeaders(object sender, EventArgs e)
{
if (Response.IsRequestBeingRedirected && (bool) (Context.Items["IsPermanentRedirect"] ?? false))
{
Response.Status = "301 Moved Permanently";
}
}
I have both Page_Error method in page that raises error, and Application_Error in global.asax. When Page throws exception, executed routine is Application_Error. But for that one particular page I would like to have different handling in Page_Error. Is there any way to achieve it?
Thanks,
Pawel
P.S. Perhaps it is because exception being thrown is caused by too large file being uploaded (I tested file upload page how it handles files bigger then web.config setting) and Page_Error is not yet wired?
From the same the function of Page_Error you can check for the page and if is the one you look you have diferent behavior.
if( HttpContext.Current.Request.Path.EndsWith("YourFileName.axd", StringComparison.InvariantCultureIgnoreCase))
{
// the diferent way
}
else
{
}
The next way is from inside the page with the diferent behavior.
public override void ProcessRequest(HttpContext context)
{
try
{
base.ProcessRequest(context);
}
catch (Exception x)
{
// here is the different, since you catch here is not move to the Page_Error
// except is a code error... in any case you can do an extra error clear.
}
}
I understand (now) that Response.Redirect() and Response.End() throw a ThreadAbortException as an expensive way of killing the current processing thread to emulate the behaviour of ASP Classic's Response.End() and Response.Redirect methods.
However.
It seems intermittently in our application that the exception bubbles too high. For example, we have a page that is called from client side javascript to return a small string to display in a page.
protected void Page_Load(object sender, EventArgs e)
{
// Work out some stuff.
Response.Write(stuff);
Response.End();
}
This generally works, but sometimes, we get the exception bubbling up to the UI layer and get part of the exception text displayed in the page.
Similarly, else where we have:
// check the login is still valid:
if(!loggedin) {
Response.Redirect("login.aspx");
}
In some cases, the user is redirected to login.aspx, in others, the user gets an ASP.NET error page and stack dump (because of how our dev servers are configured).
i.e. in some cases, response.redirect throws an exception all the way up INSTEAD of doing a redirect. Why? How do we stop this?
Have you tried overloading the default Redirect method and not ending the response?
if(!loggedin) {
Response.Redirect("login.aspx", false);
}
You can use the following best-practice code instead, as explained by this answer to prevent the exception from happening in the first place:
Response.Redirect(url, false);
Context.ApplicationInstance.CompleteRequest();
Since I was looking for an answer to this question too, I am posting what seams to me a complete solution, rounding up the two above answers:
public static void Redirect(this TemplateControl control, bool ignoreIfInvisible = true)
{
Page page = control.Page;
if (!ignoreIfInvisible || page.Visible)
{
// Sets the page for redirect, but does not abort.
page.Response.Redirect(url, false);
// Causes ASP.NET to bypass all events and filtering in the HTTP pipeline
// chain of execution and directly execute the EndRequest event.
HttpContext.Current.ApplicationInstance.CompleteRequest();
// By setting this to false, we flag that a redirect is set,
// and to not render the page contents.
page.Visible = false;
}
}
Source:
http://www.codeproject.com/Tips/561490/ASP-NET-Response-Redirect-without-ThreadAbortExcep
Our ASP.NET 2 web application handles exceptions very elegantly. We catch exceptions in Global ASAX in Application_Error. From there we log the exception and we show a friendly message to the user.
However, this morning we deployed the latest version of our site. It ran ok for half an hour, but then the App Pool crashed. The site did not come back up until we restored the previous release.
How can I make the app pool crash and skip the normal exception handler? I'm trying to replicate this problem, but with no luck so far.
Update: we found the solution. One of our pages was screenscraping another page. But the URL was configured incorrectly and the page ended up screenscraping itself infinitely, thus causing a stack overflow exception.
The most common error that I have see and "pool crash" is the loop call.
public string sMyText
{
get {return sMyText;}
set {sMyText = value;}
}
Just call the sMyText...
In order to do this, all you need to do is throw any exception (without handling it of course) from outside the context of a request.
For instance, some exception raised on another thread should do it:
protected void Page_Load(object sender, EventArgs e)
{
// Create a thread to throw an exception
var thread = new Thread(() => { throw new ArgumentException(); });
// Start the thread to throw the exception
thread.Start();
// Wait a short while to give the thread time to start and throw
Thread.Sleep(50);
}
More information can be found here in the MS Knowledge Base
Aristos' answer is good. I've also seen it done with a stupid override in the Page life cycle too when someone change the overriden method from OnInit to OnLoad without changing the base call so it recursed round in cirlces through the life cycle: i.e.
protected override void OnLoad(EventArgs e)
{
//some other most likely rubbish code
base.OnInit(e);
}
You could try throwing a ThreadAbortException.