.NET Bubbling

[oceanebelle]

Learned it today. c00l :thumb:

[BillGeek]

And what, dare I ask, is Bubbling supposed to be? :(

[MaximilianMayrhofer]

Agreed, I have no clue either..

[BillGeek]

That goodness. I was beginning to think that I know nothing about programming. (Not that I do... but anyway) :afrog:

[techgnome]

Bubbling is allowing events, information or processing to "bubble" back up to previous levels... typically with error handling, by allowing the error to bubble up back to a specific point, you can place a handler at the top level and catch it there. Sometimes this is good. Other times not so good. It just depends.

-tg

[BillGeek]

Like "try", "catch" and "throw"?

[mendhak]

Yes, you'd only need to handle it in the container control/pages. If you want to and if it's relevant to your functionality.

[oceanebelle]

And what, dare I ask, is Bubbling supposed to be? :(


Well I was experimenting yesterday about dynamically created user controls.

I have this user control that encapsulates what it does. I've placed this on a page which has data that needs updating once an action is done on a user control.

I've read about delegates however the control i'm dynamically creating is not declared as a specific instance in the page class but a generic "Control" so i'll have a hard time defining delegate handlers.

The method for handling events should be straightforward.

Basically I want the Page to be notified that "something" was done (whatever that is) on the user control and bubbling does that beautifully.

:wave:

[Merrion]

Bubbling is a new name for WM_NOTIFY :)

[BillGeek]

And a new name for "On Error Goto ErrorHandler"... :rolleyes:

Seriously though... I DO see the point in using it. What I DON'T see is why? If I have a method, that invokes another method, that in turns invoke a third method, I would want to throw an error in the third method, not the "originating" method.

Discuss?

[MaximilianMayrhofer]

True, especially if we're talking about multithreaded applications.

[mendhak]

And a new name for "On Error Goto ErrorHandler"... :rolleyes:

Seriously though... I DO see the point in using it. What I DON'T see is why? If I have a method, that invokes another method, that in turns invoke a third method, I would want to throw an error in the third method, not the "originating" method.

Discuss?
The exception can be thrown anywhere, but it's really about where you handle it, isn't it? If you reference a third party class library, you'd rather handle the exception yourself rather than having the DLL handle it in its own way with, say, a log file. You may want all your exceptions in one place such as the event viewer.

[oceanebelle]

And a new name for "On Error Goto ErrorHandler"... :rolleyes:


Which gets me to wonder why .NET created "Exceptions" and just stuck to that for event generation?

Catching exceptions is different from directing flow of the program, so I do not understand why bubbling is likened to it.

[techgnome]

Because there's no guarantee that the error ocurrs in the same thread as the application that will handle it. The program flow can't cross threads (insert reference to 80's movie in which crossing streams is indicated to be a bad thing) so it has to be passed back up the chain some how, safely crossing from one thread to the next. Enter Delegates, which in essence an event handler. When the offending code burps, it throws a flag, and yells "HEY SOMETHING WENT S#$^ HERE!" ... and any one listening to that delegate (because it couldbe connected by more than one process) gets the notification that the thread has gone south and action needs to be taken.

-tg

[FunkyDexter]

Discuss? If you've got a method that can be called from several different places in your program, what constitutes an error in one of those places might be perfectly acceptable in another.

For example, say you've got a function that finds the price of a given sales item. It's possible that the item won't be found in the inventory
(e.g. it's been deleted). In one place it might be acceptable to just use a price of zero in this scenario, another part of your code might want to report the missing item to the user, a third might want to generate the missing item automatically. Your function doesn't have enough information to make that decision so you can't handle it there. Instead you need to let the calling code know that the item was missing and the easiest way to do that is to throw an exception up the stack.

I have no idea if this is anything to do with 'Bubbling' but I'm right behind the try/throw/catch error handling aproach. It's far more powerful than trying to handle every error where it occurs.

[oceanebelle]

Because there's no guarantee that the error ocurrs in the same thread as the application that will handle it. The program flow can't cross threads (insert reference to 80's movie in which crossing streams is indicated to be a bad thing) so it has to be passed back up the chain some how, safely crossing from one thread to the next. Enter Delegates, which in essence an event handler. When the offending code burps, it throws a flag, and yells "HEY SOMETHING WENT S#$^ HERE!" ... and any one listening to that delegate (because it couldbe connected by more than one process) gets the notification that the thread has gone south and action needs to be taken.

-tg


Is bubbling and the use of delegates the same?

And of the three which is more expensive in terms of server resources used when one of them happens?

[mendhak]

They are complementary, not different.

You need a delegate to specify an event. Read (http://www.odetocode.com/code/94.aspx).

Whatever you do, it'll always be expensive, as it constitutes more cycles to perform your new code.

As for error handling, if you're going to catch, handle and throw an error again, that too is quite expensive.