Base Page Design Question

20 Jul 2005 11:22 PM

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
RaisePostBackEvent. The RaisePostBackEvent 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 RaiseChangedEvents. 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.

21 Jul 2005 7:27 AM

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.GetLastError

' Write error to log file or something ...

' Show Error on screen

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

End Sub

HTH,
Jurjen.

Show quoteHide quote

"Tony" <octo_remove***@optusnet.com.au> wrote in message
news:%23g8b7KYjFHA.576@tk2msftngp13.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
> RaisePostBackEvent. The RaisePostBackEvent 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 RaiseChangedEvents. 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.
>
>
>
>

21 Jul 2005 11:00 AM

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.

Show quoteHide quote

"Jurjen de Groot" <i***@gits-online.nl> wrote in message
news:%23ch3IWcjFHA.1412@TK2MSFTNGP09.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.GetLastError
>
> ' Write error to log file or something ...
>
> ' Show Error on screen
>
> ' Clear error so that it does not buble up to Application Level
> Server.ClearError()
>
> End Sub
>
> HTH,
> Jurjen.
>
>
>
> "Tony" <octo_remove***@optusnet.com.au> wrote in message
> news:%23g8b7KYjFHA.576@tk2msftngp13.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
>> RaisePostBackEvent. The RaisePostBackEvent 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 RaiseChangedEvents. 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.
>>
>>
>>
>>
>
>

21 Jul 2005 7:02 PM

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:news-re***@joergjooss.de

21 Jul 2005 10:57 PM

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 ApplicationException 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 programmatically 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.

Show quoteHide quote

"Joerg Jooss" <news-re***@joergjooss.de> wrote in message
news:xn0e50rizbftnhn004@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:news-re***@joergjooss.de