Base Page Design Question

[Tony]

I am in the process of setting up a base page model for multiple reasons.
One of the reasons is so that I can catch all exceptions when derived pages
throw/raise them. I don't want to use the standard OnError virtual method to
handle this requirement because the form does not complete its rendering
process when this occurs. I really need the form to display properly on the
screen.

I have managed to catch nearly all exceptions by overriding the following
virtual methods in the base page: OnInit, OnLoad, OnUnload and
RaisePostBackEv ent. The RaisePostBackEv ent virtual method is ideal for
capturing post back events triggered by Web controls, such as button clicks.
What is missing from this model is the ability to capture the changed event
that Web controls may raise/throw. This path is routed via a separate page
method called RaiseChangedEve nts. This method is unfortunately both non
virtual and private.

Currently my work around is to subclass all Web controls and wrap exception
handling inside their own OnXXX virtual methods. Can anyone suggest a better
solution or work around here please?

Thanks in advance,

Tony.

[Jurjen de Groot]

Tony,

Protected Overrides Sub OnInit(ByVal e As EventArgs)

MyBase.OnInit(e )

AddHandler Me.Error, AddressOf PageBase_Error

End Sub

Protected Sub PageBase_Error( ByVal Sender As Object, ByVal e As EventArgs)

Dim curError As Exception = Server.GetLastE rror

' Write error to log file or something ...

' Show Error on screen

' Clear error so that it does not buble up to Application Level
Server.ClearErr or()

End Sub

HTH,
Jurjen.

"Tony" <oc************ @optusnet.com.a u> wrote in message
news:%2******** *******@tk2msft ngp13.phx.gbl.. .

I am in the process of setting up a base page model for multiple reasons.
One of the reasons is so that I can catch all exceptions when derived pages
throw/raise them. I don't want to use the standard OnError virtual method
to handle this requirement because the form does not complete its rendering
process when this occurs. I really need the form to display properly on the
screen.

I have managed to catch nearly all exceptions by overriding the following
virtual methods in the base page: OnInit, OnLoad, OnUnload and
RaisePostBackEv ent. The RaisePostBackEv ent virtual method is ideal for
capturing post back events triggered by Web controls, such as button
clicks. What is missing from this model is the ability to capture the
changed event that Web controls may raise/throw. This path is routed via a
separate page method called RaiseChangedEve nts. This method is
unfortunately both non virtual and private.

Currently my work around is to subclass all Web controls and wrap
exception handling inside their own OnXXX virtual methods. Can anyone
suggest a better solution or work around here please?

Thanks in advance,

Tony.

[Tony]

Thanks for your tip Jurjen but as I stated in my original message, handling
exceptions inside OnError prevents ASP.NET from rendering the Web form. This
is a major requirement for me, unless someone knows of a way to get the .NET
framework to render a Web form once OnError has caught an exception? If so,
then I can avoid subclassing every .NET Web control.

Regards,
Tony.
"Jurjen de Groot" <in**@gits-online.nl> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

Tony,

Protected Overrides Sub OnInit(ByVal e As EventArgs)

MyBase.OnInit(e )

AddHandler Me.Error, AddressOf PageBase_Error

End Sub

Protected Sub PageBase_Error( ByVal Sender As Object, ByVal e As EventArgs)

Dim curError As Exception = Server.GetLastE rror

' Write error to log file or something ...

' Show Error on screen

' Clear error so that it does not buble up to Application Level
Server.ClearErr or()

End Sub

HTH,
Jurjen.

"Tony" <oc************ @optusnet.com.a u> wrote in message
news:%2******** *******@tk2msft ngp13.phx.gbl.. .

I am in the process of setting up a base page model for multiple reasons.
One of the reasons is so that I can catch all exceptions when derived
pages throw/raise them. I don't want to use the standard OnError virtual
method to handle this requirement because the form does not complete its
rendering process when this occurs. I really need the form to display
properly on the screen.

I have managed to catch nearly all exceptions by overriding the following
virtual methods in the base page: OnInit, OnLoad, OnUnload and
RaisePostBackEv ent. The RaisePostBackEv ent virtual method is ideal for
capturing post back events triggered by Web controls, such as button
clicks. What is missing from this model is the ability to capture the
changed event that Web controls may raise/throw. This path is routed via
a separate page method called RaiseChangedEve nts. This method is
unfortunately both non virtual and private.

Currently my work around is to subclass all Web controls and wrap
exception handling inside their own OnXXX virtual methods. Can anyone
suggest a better solution or work around here please?

Thanks in advance,

Tony.

[Joerg Jooss]

Tony wrote:

I am in the process of setting up a base page model for multiple
reasons. One of the reasons is so that I can catch all exceptions
when derived pages throw/raise them. I don't want to use the standard
OnError virtual method to handle this requirement because the form
does not complete its rendering process when this occurs. I really
need the form to display properly on the screen.

Isn't this a bogus requirement? If there's an exception while rendering
a page, how can you ever be sure to render the rest of the page in a
meaningful way?

Cheers,
--
http://www.joergjooss.de
mailto:ne****** **@joergjooss.d e

[Tony]

Yes and no.

Yes because if a system throws an exception then it makes sense to redirect
a user to a different page altogether because like you said, who knows what
state the page could be in.

No because we are using a sub classed rendition of ApplicationExce ption to
act as a user error exception, thus allowing us trap all user errors at a
default (common) location and render the error on the same page with all
controls in tact because like I said, in the end it's a user error not a
system exception. For our requirement, when a user error is raised in a
large and complex system it would be appropriate to automatically unwind the
call stack to the top-most level and render the user error message on the
same Web page with all controls in tact. Regardless, we have to place
try/finally statements throughout our code to ensure that we close all
opened resources when an exception is thrown, such as database connections.
Now you might say that overloading exception handling this way was not its
intention and I will agree with you, but this solution allows us to code
error handling securely and with minimal effort. This error handling model
avoids us from unwinding the call stack programmaticall y by checking the
return value of every function call (and there many of them), thus making
the code bloated, less readable and prone to failure by missing a few checks
along the way.

Hope this helps in the understanding of our system design requirement.

Regards,
Tony.
"Joerg Jooss" <ne********@joe rgjooss.de> wrote in message
news:xn******** ********@msnews .microsoft.com. ..

Tony wrote:

I am in the process of setting up a base page model for multiple
reasons. One of the reasons is so that I can catch all exceptions
when derived pages throw/raise them. I don't want to use the standard
OnError virtual method to handle this requirement because the form
does not complete its rendering process when this occurs. I really
need the form to display properly on the screen.

Isn't this a bogus requirement? If there's an exception while rendering
a page, how can you ever be sure to render the rest of the page in a
meaningful way?

Cheers,
--
http://www.joergjooss.de
mailto:ne****** **@joergjooss.d e