Having a difficult time coding an Application_Error() event handler

Question

3.40/5 (3 votes)

See more:

I'm trying to code an Application_Error() event handler for my application.

Code works, but if I removed file permissions on the file that the program is trying to access the error that called the Application Error() handler is displayed as a server error instead of an IO Exception.

This code is loosely based off of this: http://www.asp.net/web-forms/tutorials/aspnet-45/getting-started-with-aspnet-45-web-forms/aspnet-error-handling[^]

C#

protected void Application_Error(object sender, EventArgs e)
        {
                Exception exc = Server.GetLastError();
                Guid g = Guid.NewGuid();
                if (exc is HttpUnhandledException)
                {
                    if (exc.InnerException != null)
                    {
                        #region WriteToLog
                        //write and modify permissions required for local\IIS_IUSERS on App_Data
                        string filepath = "~/App_Data/ErrorLog.txt";
                        filepath = HttpContext.Current.Server.MapPath(filepath);

                        if (!File.Exists(filepath))
                            File.Create(filepath);

                        StreamWriter sW = new StreamWriter(filepath, true, Encoding.UTF8);
                        try
                        {
                            sW.WriteLine("********** {0} **********", DateTime.Now);
                            sW.Write("Guid: ");
                            sW.WriteLine(g.ToString());
                            if (exc.InnerException != null)
                            {
                                sW.Write("Inner Exception Type: ");
                                sW.WriteLine(exc.InnerException.GetType().ToString());
                                sW.Write("Inner Exception: ");
                                sW.WriteLine(exc.InnerException.Message);
                                sW.Write("Inner Source: ");
                                sW.WriteLine(exc.InnerException.Source);
                                if (exc.InnerException.StackTrace != null)
                                {
                                    sW.WriteLine("Inner Stack Trace: ");
                                    sW.WriteLine(exc.InnerException.StackTrace);
                                }
                            }
                            sW.Write("Exception Type: ");
                            sW.WriteLine(exc.GetType().ToString());
                            sW.WriteLine("Exception: " + exc.Message);
                            //sW.WriteLine("Source: " + source);
                            sW.WriteLine("Stack Trace: ");
                            if (exc.StackTrace != null)
                            {
                                sW.WriteLine(exc.StackTrace);
                                sW.WriteLine();
                            }
                        }
                        finally
                        {
                            sW.Close();
                        }

                        #endregion

                        string message = (exc.InnerException.Message != null) ? exc.InnerException.Message : exc.Message;
                        string pageToTransferTo = "~/ErrorPage.aspx?GUID=" + g.ToString() + "&Message=" + message;

                        Server.Transfer(pageToTransferTo);

                    }
                }
        }

Posted 15-Aug-13 6:11am

Kyle Gottfried

Updated 15-Aug-13 7:47am

v5

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-08-15T06:24:00

Solution 1

The first mistake I can see is this:

C#

try {
   //...
} catch (Exception ex) {
   throw ex;
}

is functionally strictly equivalent to not handling exceptions at all and

C#

try {
   Something();
} catch (Exception ex) {
   throw ex;
} finally {
   SomethingElse();
}

is functionally strictly equivalent to

C#

try {
   Something();
} finally {
   SomethingElse();
}

Beyond functional equivalence: you are just wasting time and resources for doing nothing. Just don't catch and handle this way. In first case, don't use try-catch at all.

This and your other question show that you have no clue on two critically important topics: exceptions and events. I don't know a good way to help you more effectively before you do the following: pause all you are doing and study this two topic in detail. Practice on very simple examples, not on HTTP, networking UI or any other advanced topic. Seriously. Before you master it, you would just waste your time.

[EDIT]

After getting this answer, OP fixed the problems mentioned above, in the body of the question. Of course, it still requires to think at the major problem.

—SA

Posted 15-Aug-13 6:24am

Sergey Alexandrovich Kryukov

Updated 15-Aug-13 9:11am

v2

Comments

Kyle Gottfried 15-Aug-13 13:01pm

You can be critical all you want, and I agree, I have not had as much experience as I should have on event handlers.
This code sample is sloppy, I know that. Primarily it's sloppy because I was trying to get information back besides a Server error for the error that called the Application_Error() event.

The was a difficult issue because something that was working when debugging in an Local IIS Web Server there were no errors and when I ran it on IIS without the aid of VS it failed.

The least you could to is try to help someone out with a question not just slam them for some sloppy code and walk out the door. It's rude and leaves everyone in a bad mood.

None of my other code makes the same simply mistakes that I made here.

And my previous question? It was a perfectly good question. As an event is raised when the application has an error and is handled by the Application_Error() method, an error inside that method may simply raise the Application Error event again causing an endless loop. I have no idea why anyone closed the question.

And for your information, I figured out what the problem was myself. IIS did not have Create or Modify permissions on the folder which the Error log file was stored.

Sergey Alexandrovich Kryukov 15-Aug-13 13:05pm

I would gladly answer your other question if not your rudeness with someone who politely talked to you and spent good time trying to help you.
Sorry, no more.

Note: OP removed last line from the comment, to look it nos so outrageous. Much better.

—SA

Kyle Gottfried 15-Aug-13 13:42pm

That was me that removed the last line, not an op.

Sergey Alexandrovich Kryukov 15-Aug-13 13:45pm

I know. Unfortunately, we have bad jargon here: OP is you, it means Original Poster or something like that. Sorry about confusion.
—SA

Sergey Alexandrovich Kryukov 15-Aug-13 13:44pm

Okay, I gave you recommendation and strongly suggest you follow my advice. Even if you solved your problem, it will haunt you later until you learn those critically important topics.
Your attitude of confrontation when you hear something you don't like won't server you well. If I did not advise you to learn it all, would you feel better? You actually did not solve the root of the problem, correct handling of application error, you just removed the error, but this is not the only possible one.
—SA

Kyle Gottfried 15-Aug-13 13:47pm

Code has been updated. Some changes made and extra catches removed.

Code works, but if I removed file permissions on the file that the program is trying to access the error that called the Application Error() handler is displayed as a server error instead of an IO Exception.

Kyle Gottfried 15-Aug-13 13:53pm

I tried moving Server.Clear() to line 4, which should clear the error that called Application_Error() in the first place, allowing exc to keep the Exception around to log it to the log file.

However, doing this just causes a blank page to appear on the web browser.

Sergey Alexandrovich Kryukov 15-Aug-13 14:27pm

I didn't get it. Are you saying you still have a problem? or another problem?
—SA

Kyle Gottfried 15-Aug-13 15:00pm

The former. The current issue with the code right now is that in the event that say, the streamwriter fails to open or the like instead of spitting out the associated IO Exception to the webpage the Exception that originally caused the Application_Error method to be called in the first place is sent to the webpage.

Sergey Alexandrovich Kryukov 15-Aug-13 15:18pm

Okay, next step would be running through this point under debugger, of possible. I could be difficult, so the stack trace you already output can help a lot. Does the point where the exception is originally thrown shown in the stack trace? Additionally, you may need to show all exception information, in particular, InnerException (recursively). If there is a bug in the code throwing exception which you cannot fix, perhaps you could show that fragment of code, with proper explanation.

Probably, you should not expose all that in the working version of the site, as it usually considered unsafe. As the alternative, people use logging, it only goes to the server side.

—SA