Server.GetLastError() and "Page-Level Error Pages"

[José Joye]

Hello,
I'm currently reading the MS Developing Web applications with c# (and
VB.net).

In the chapter related to Error management, there is a sample about
"Page-Level Error Pages"

eg:
In my form:
========
<%@ Page language="c#" Codebehind="TestErrOnPage.aspx.cs"
AutoEventWireup="false" Inherits="myDummyTry.TestErrOnPage"
errorPage="ErrDefault1.aspx"%>

I have placed a button on the form and in the code behind just thrown an
Exception.
in ErrDefaulst1.aspx:
==============

private void Page_Load(object sender, System.EventArgs e)
{
if (Server.GetLastError() != null)
litError.Text="<h3>" + Server.GetLastError().Message + "</h3>";
else
litError.Text= "<h3>Unkown Error occured...</h3>";
Server.ClearError();
}
It is said, that is is possible to use the Server.GetLastError() in the
error page. However, it is always null.
Did I miss something?

Thanks,
José

[Lars Netzel]

I asked this.. and got answered by myself:) a few days ago..

My answer:

"Since you are redirected to another errorpage you loose the GetLatsetError
information, cause you are not on that page anymore.. BUT.. if you in
Global.aspx in Page_Eerror event (where it's still accessible) put
Server.GetLastError in a SESSION variable.. you can get it thru that on the
Errorpage .."

/Lars

"José Joye" <jo*******@KILLTHESPAMSbluewin.ch> skrev i meddelandet
news:us**************@TK2MSFTNGP11.phx.gbl...

Hello,
I'm currently reading the MS Developing Web applications with c# (and
VB.net).

In the chapter related to Error management, there is a sample about
"Page-Level Error Pages"

eg:
In my form:
========
<%@ Page language="c#" Codebehind="TestErrOnPage.aspx.cs"
AutoEventWireup="false" Inherits="myDummyTry.TestErrOnPage"
errorPage="ErrDefault1.aspx"%>

I have placed a button on the form and in the code behind just thrown an
Exception.
in ErrDefaulst1.aspx:
==============

private void Page_Load(object sender, System.EventArgs e)
{
if (Server.GetLastError() != null)
litError.Text="<h3>" + Server.GetLastError().Message + "</h3>";
else
litError.Text= "<h3>Unkown Error occured...</h3>";
Server.ClearError();
}
It is said, that is is possible to use the Server.GetLastError() in the
error page. However, it is always null.
Did I miss something?

Thanks,
José

[José Joye]

Thanks for the answer. However, I'm not too clear about it.

1) I thaught that the Page_Error() method has to be located in the Web class
and not in the Global.aspx. Did I misundertood what you explained me.

2) With the following:
<%@ Page language="c#" Codebehind="TestErrOnPage.aspx.cs"
AutoEventWireup="false" Inherits="myDummyTry.TestErrOnPage"
errorPage="ErrDefault1.aspx"%>
I was trying to get rid of the Page_Error() method and have a "kind of
automatic" redirection to the ErrDefault1.aspx page in case of error.
If I make usage of the Page_Error() method, I do not see the reason of
having the "errorPage="ErrDefault1.aspx"%>" statement in my aspx file.

Thanks,
José

"Lars Netzel" <[stop_spam]@host.topdomain> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

I asked this.. and got answered by myself:) a few days ago..

My answer:

"Since you are redirected to another errorpage you loose the GetLatsetError information, cause you are not on that page anymore.. BUT.. if you in
Global.aspx in Page_Eerror event (where it's still accessible) put
Server.GetLastError in a SESSION variable.. you can get it thru that on the Errorpage .."

/Lars

"José Joye" <jo*******@KILLTHESPAMSbluewin.ch> skrev i meddelandet
news:us**************@TK2MSFTNGP11.phx.gbl...

Hello,
I'm currently reading the MS Developing Web applications with c# (and
VB.net).

In the chapter related to Error management, there is a sample about
"Page-Level Error Pages"

eg:
In my form:
========
<%@ Page language="c#" Codebehind="TestErrOnPage.aspx.cs"
AutoEventWireup="false" Inherits="myDummyTry.TestErrOnPage"
errorPage="ErrDefault1.aspx"%>

I have placed a button on the form and in the code behind just thrown an
Exception.
in ErrDefaulst1.aspx:
==============

private void Page_Load(object sender, System.EventArgs e)
{
if (Server.GetLastError() != null)
litError.Text="<h3>" + Server.GetLastError().Message + "</h3>";
else
litError.Text= "<h3>Unkown Error occured...</h3>";
Server.ClearError();
}
It is said, that is is possible to use the Server.GetLastError() in the
error page. However, it is always null.
Did I miss something?

Thanks,
José

[Duncan Kennedy]

Hi José,

I think Lars is suggesting having the exception handled, or at least its
details stored somewhere, in the Application_Error method in "Global.asax".

It may be that perhaps your exception page doesn't need to show the
details of the exception to the end user, although I, of course, don't
know the details of your scenario. If you're principally interested in
apologizing to the user and publishing the details of the exception
somewhere developers can get hold of it (event log, email, file etc) you
could use Microsoft Exception Management Application block from:

http://msdn.microsoft.com/library/de...ml/emab-rm.asp
You could get around adding errorPage and Page_Error() code your
individual aspx pages by also setting the default error redirect in your
webconfig <customErrors> section:

<customErrors mode="On" defaultRedirect="ErrorPage.aspx">
</customErrors>

(mode attribute is explained in the comments preceding the section in
web.config, "On" is likely to be necessary for testing and debugging if
you're serving the pages from your own machine)

In this way your page exception would not get handled on the page, would
propogate to the Global.asax handler, which would publish the exception
to whatever log your wanted, or perhaps store it in some accessible
storage, and *not* clear the error. Then the exception would propogate
to the defaultRedirect page in the web.config file, which could
apologize to the user and possibly use any persisted exception details.

This works quite neatly, although it is worth noting that any resources
not handled by the ASP.NET isapi filter (for instance any legacy asp
pages you may be obliged to include) will require additional handling.

There may well be faults with this method of handling things, and to be
honest it feels a little cumbersome defaulting to allowing the exception
to escalate to the application level, but I've certainly been obliged to
do it, and application level handling definitely should exist.

Hope I didn't deviate to far from your question!
Regards,
Duncan Kennedy.

[José Joye]

Hi Duncan,

Thanks a lot for your really interesting reply.
I'm actually in the process of getting up to speed with ASP.NET (sorry for
the stupid questions ;-) )

I still have an open question related to this topic.
Say an exception is thrown in the Rendering part (preRendering/Rendering) of
the form.
This is actually out my scope. In that situation, if I do not have a
Page_Error() defined, how could I record the kind of error that occured.
If I understand it correctly, as soon as I get out of the Page scope, I will
not have the exception available anymore if I did not save it manually
somewhere (eg. : Session bag).

If I defined an Application_Error handler (in Global.asax) will I have this
information available?

Thanks,
José
"Duncan Kennedy" <yo*****************************@achilles.com> wrote in
message news:uc**************@tk2msftngp13.phx.gbl...

Hi José,

I think Lars is suggesting having the exception handled, or at least its
details stored somewhere, in the Application_Error method in "Global.asax".
It may be that perhaps your exception page doesn't need to show the
details of the exception to the end user, although I, of course, don't
know the details of your scenario. If you're principally interested in
apologizing to the user and publishing the details of the exception
somewhere developers can get hold of it (event log, email, file etc) you
could use Microsoft Exception Management Application block from:

http://msdn.microsoft.com/library/de...ml/emab-rm.asp

You could get around adding errorPage and Page_Error() code your
individual aspx pages by also setting the default error redirect in your
webconfig <customErrors> section:

<customErrors mode="On" defaultRedirect="ErrorPage.aspx">
</customErrors>

(mode attribute is explained in the comments preceding the section in
web.config, "On" is likely to be necessary for testing and debugging if
you're serving the pages from your own machine)

In this way your page exception would not get handled on the page, would
propogate to the Global.asax handler, which would publish the exception
to whatever log your wanted, or perhaps store it in some accessible
storage, and *not* clear the error. Then the exception would propogate
to the defaultRedirect page in the web.config file, which could
apologize to the user and possibly use any persisted exception details.

This works quite neatly, although it is worth noting that any resources
not handled by the ASP.NET isapi filter (for instance any legacy asp
pages you may be obliged to include) will require additional handling.

There may well be faults with this method of handling things, and to be
honest it feels a little cumbersome defaulting to allowing the exception
to escalate to the application level, but I've certainly been obliged to
do it, and application level handling definitely should exist.

Hope I didn't deviate to far from your question!
Regards,
Duncan Kennedy.

[Duncan Kennedy]

Hi José,

I'm sorrier for the stupid answers...

If an exception either occurs on a page before a Page_Error() handler
has been assigned or is not cleared by by a Page_Error() method then the
application will throw a HttpUnhandledException exception, which will
contain in its "innerException" property the exception that was
unhandled on the page.

As such you should still have your page exception when you're coding at
the Application_Error level, it will just be wrapped in another
exception. You could persist this somewhere appropriate if you wanted
to keep it to give a verbose report to the user when you finally
transferred the scope to an error page (Server.Redirect, defaultError in
web.config etc).

I hope this helps, Michael O'Donovan pointed out the following url on
error handling in another thread which might be useful:

http://msdn.microsoft.com/asp.net/us...stomErrors.asp

Best of luck,

Duncan.


José Joye wrote:

Hi Duncan,

Thanks a lot for your really interesting reply.
I'm actually in the process of getting up to speed with ASP.NET (sorry for
the stupid questions ;-) )

I still have an open question related to this topic.
Say an exception is thrown in the Rendering part (preRendering/Rendering) of
the form.
This is actually out my scope. In that situation, if I do not have a
Page_Error() defined, how could I record the kind of error that occured.
If I understand it correctly, as soon as I get out of the Page scope, I will
not have the exception available anymore if I did not save it manually
somewhere (eg. : Session bag).

If I defined an Application_Error handler (in Global.asax) will I have this
information available?

Thanks,
José
"Duncan Kennedy" <yo*****************************@achilles.com> wrote in
message news:uc**************@tk2msftngp13.phx.gbl...

Hi José,

I think Lars is suggesting having the exception handled, or at least its
details stored somewhere, in the Application_Error method in

"Global.asax".

It may be that perhaps your exception page doesn't need to show the
details of the exception to the end user, although I, of course, don't
know the details of your scenario. If you're principally interested in
apologizing to the user and publishing the details of the exception
somewhere developers can get hold of it (event log, email, file etc) you
could use Microsoft Exception Management Application block from:

http://msdn.microsoft.com/library/de...ml/emab-rm.asp

You could get around adding errorPage and Page_Error() code your
individual aspx pages by also setting the default error redirect in your
webconfig <customErrors> section:

<customErrors mode="On" defaultRedirect="ErrorPage.aspx">
</customErrors>

(mode attribute is explained in the comments preceding the section in
web.config, "On" is likely to be necessary for testing and debugging if
you're serving the pages from your own machine)

In this way your page exception would not get handled on the page, would
propogate to the Global.asax handler, which would publish the exception
to whatever log your wanted, or perhaps store it in some accessible
storage, and *not* clear the error. Then the exception would propogate
to the defaultRedirect page in the web.config file, which could
apologize to the user and possibly use any persisted exception details.

This works quite neatly, although it is worth noting that any resources
not handled by the ASP.NET isapi filter (for instance any legacy asp
pages you may be obliged to include) will require additional handling.

There may well be faults with this method of handling things, and to be
honest it feels a little cumbersome defaulting to allowing the exception
to escalate to the application level, but I've certainly been obliged to
do it, and application level handling definitely should exist.

Hope I didn't deviate to far from your question!
Regards,
Duncan Kennedy.

[José Joye]

Thanks a lot for the explanation and for the great reference. I think that
I'm pretty clear on this topic now :-))
José
"Duncan Kennedy" <yo*****************************@achilles.com> a écrit dans
le message de news:eu**************@tk2msftngp13.phx.gbl...

Hi José,

I'm sorrier for the stupid answers...

If an exception either occurs on a page before a Page_Error() handler
has been assigned or is not cleared by by a Page_Error() method then the
application will throw a HttpUnhandledException exception, which will
contain in its "innerException" property the exception that was
unhandled on the page.

As such you should still have your page exception when you're coding at
the Application_Error level, it will just be wrapped in another
exception. You could persist this somewhere appropriate if you wanted
to keep it to give a verbose report to the user when you finally
transferred the scope to an error page (Server.Redirect, defaultError in
web.config etc).

I hope this helps, Michael O'Donovan pointed out the following url on
error handling in another thread which might be useful:

http://msdn.microsoft.com/asp.net/us...stomErrors.asp
Best of luck,

Duncan.


José Joye wrote:

Hi Duncan,

Thanks a lot for your really interesting reply.
I'm actually in the process of getting up to speed with ASP.NET (sorry for the stupid questions ;-) )

I still have an open question related to this topic.
Say an exception is thrown in the Rendering part (preRendering/Rendering) of the form.
This is actually out my scope. In that situation, if I do not have a
Page_Error() defined, how could I record the kind of error that occured.
If I understand it correctly, as soon as I get out of the Page scope, I will not have the exception available anymore if I did not save it manually
somewhere (eg. : Session bag).

If I defined an Application_Error handler (in Global.asax) will I have this information available?

Thanks,
José
"Duncan Kennedy" <yo*****************************@achilles.com> wrote in
message news:uc**************@tk2msftngp13.phx.gbl...

Hi José,

I think Lars is suggesting having the exception handled, or at least its
details stored somewhere, in the Application_Error method in

"Global.asax".

It may be that perhaps your exception page doesn't need to show the
details of the exception to the end user, although I, of course, don't
know the details of your scenario. If you're principally interested in
apologizing to the user and publishing the details of the exception
somewhere developers can get hold of it (event log, email, file etc) you
could use Microsoft Exception Management Application block from:

http://msdn.microsoft.com/library/de...ml/emab-rm.asp

You could get around adding errorPage and Page_Error() code your
individual aspx pages by also setting the default error redirect in your
webconfig <customErrors> section:

<customErrors mode="On" defaultRedirect="ErrorPage.aspx">
</customErrors>

(mode attribute is explained in the comments preceding the section in
web.config, "On" is likely to be necessary for testing and debugging if
you're serving the pages from your own machine)

In this way your page exception would not get handled on the page, would
propogate to the Global.asax handler, which would publish the exception
to whatever log your wanted, or perhaps store it in some accessible
storage, and *not* clear the error. Then the exception would propogate
to the defaultRedirect page in the web.config file, which could
apologize to the user and possibly use any persisted exception details.

This works quite neatly, although it is worth noting that any resources
not handled by the ASP.NET isapi filter (for instance any legacy asp
pages you may be obliged to include) will require additional handling.

There may well be faults with this method of handling things, and to be
honest it feels a little cumbersome defaulting to allowing the exception
to escalate to the application level, but I've certainly been obliged to
do it, and application level handling definitely should exist.

Hope I didn't deviate to far from your question!
Regards,
Duncan Kennedy.