Re: Consuming your own events.

I personally have to disagree with your main point which is "overridable is
bad because people can omit to call the base method". Well then, the same
applies to constructors.

If I override a method and don't call the base,
I expect the base code to not be executed. Nothing more, nothing less. Now,
if that cause all kind of side effects, then yes, this is bad design and is
the main argument for not making methods virtual by default like in Java.
Offering too much is worse than not enough.

Sébastien

On 1/29/08, Sebastien Lambla <[email protected]> wrote:
>
> > the guideline clearly state that non-sealed classes that expose events
> > should implement a:
> > protected virtual void OnTheEvent( EventArgs e ) for every public
> > event.
>
> Guidelines are just that, guidelines. They're not always right, and over
> time the get more wrong.
>
> The problem with the OnXxx notation is that it's overloaded with meaning.
> Some class libraries put the event raising on it, others use it for
> handlers. The intent of the overriding mechanism can only be described in
> the documentation, and calling base.OnXxx is up to the developer. It's in
> my
> opinion quite a poor design.
>
> If you want to cancel an event, have a CancelableEventArgs with a bool
> Cancel property, raise it through the RaiseXxx method. Have all the
> handlers
> in the form HandleXxx. Adopt the Xxxing / Xxxed notation to provide for
> ordering. Provide an optional OnXxx that is called before the event and
> can
> cancel it, having essentially the semantics of an event handler attached
> to
> the instance of a type, something that is quite common in WPF where
> attached
> events are docked to a type through the OnXxx method.
>
> I find the code semantics of "ea.Cancel = true" much better than the
> semantics of not calling the base class as a way to cancel an event.
>
> If your object is in an undeterministic state if throwing when the event
> is
> raised, so will it with overridden OnXxx that forgets to call the base
> class
> implementation.
>
> I've seen way too many issues all around the semantics of calling
> base.OnXxx, where it is sometimes needed, sometimes not, and never visible
> in the code, to find the common meme on event raising / handling to be
> either sufficient or in any way accurate.
>
> It's a bit like the Begin / End async handling where people were quite
> wrong
> for years on the necessity to call End because the semantics were left to
> documentation.
>
>
> --
> SerialSeb
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>



-- 
Sébastien
www.sebastienlorion.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com