Re: Consuming your own events.

<quote>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.
</quote>
I am not sure this is 100% right.  I think (certainly in c#) that the
compiler will call the default constructor on the base class if there is
one, and fail to compile if there is not.
I do not know if this holds true for other languages or if it's a CLR
feature.

I don't like the way that not calling a base method and not calling the base
implementation can stop an event from firing in a lot of the framework, but
that is the cost of the pipeline style of programming being used.
OnXXX does give you a way to perform some actions in your derived class
before and after any subscribers to the event are called, including catching
exceptions thrown by the subscribers.  It also provides a way of hooking
into the base objects pipeline in a more predictable way.

On the other hand always calling base is an easy rule to remember, along
with always add a comment if you don't call it or if you must call it at the
beginning/end so the rest of us maintaining/inheriting can understand what
it does and why.
HTH

James

On Jan 30, 2008 4:57 AM, Sébastien Lorion <[email protected]>
wrote:

> 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(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>

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

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