That sounds like a good idea to me; IMHO the exception handling should be
caught and output with a stack dump (it’s frustrating having to run with catch
all exceptions turned on)
John
> On 21 May 2015, at 07:19, Florin Jurcovici <florin.jurcov...@gmail.com> wrote:
>
> Here's a test to describe what happens (sorry for the lost indentation):
>
> qx.Class.define("com.flj.sketchbook.test.MiscTest",
> {
> extend : qx.dev.unit.TestCase,
> members :
> {
> "test: 00. exception in event handler breaks event firer": function()
> {
> var listener = new qx.core.Object();
> listener.onEvent = function()
> {
> throw "listener failure which should not break event source";
> }
> var firer = new qx.core.Object();
> firer.completedSuccessfully = false;
> firer.fireEvent = function()
> {
> this.fireDataEvent("testEvent");
> this.completedSuccessfully = true;
> }
> firer.addListener("testEvent", listener.onEvent, listener);
> try
> {
> firer.fireEvent();
> this.assertTrue(firer.completedSuccessfully);
> }
> catch(ex)
> {
> this.fail("Exception propagated :-(");
> }
> }
> }
> });
>
> My thinking: when you deal with bubbling events, you might want errors to
> propagate, the same way as native events themselves do, through a hierarchy
> of nested objects. But with non-bubbling, data-only events, you just want to
> provide notifications to whoever might be interested in your state changes,
> you don't want to couple your self to whoever might be interested in
> listening to your events. If an error occurs, handling it should be the
> responsibility of whoever listens to your state changes, not yours.
>
> My impression is that the best place to add this is in
> qx.core.MEvent.fireDataEvent(), since it's the most specific, highest level.
>
> Haven't tried out the impact on existing tests so far, but don't expect to be
> any - since it isn't in place, tests currently must check all errors
> themselves, so adding a try/catch will not catch anything, for the time being.
>
> Is this a good idea for a change? If yes, is qx.core.MEvent.fireDataEvent()
> the right place to put it into? If yes, should I file a bug/submit a
> patch/submit a pull request?
>
> Simple rules (...) lead to complex behavior. Complex rules (...) lead to
> stupid behavior. (Getting Real, 37Signals - now Basecamp)
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
