Hitachi Vantara Pentaho Community Forums
Results 1 to 5 of 5

Thread: Avoid FBY (frustration by crash) and loss of design changes on UI exceptions

  1. #1
    Jens Bleuel Guest

    Default Avoid FBY (frustration by crash) and loss of design changes on UI exceptions

    Hi all,

    the problem:
    ------------
    It's very rare these days, but it still happens:
    User designs a very nice transformation or job and a nasty bug knocks on
    the door and crashes spoon... and the hole work since the last save is
    lost in space.
    An example is PDI-1257 and when you search for "crash" in jira you find
    some more.

    The reason for this is that most of the added listeners to swt events
    are not secured with a try/catch block.

    When you look for example at TransGraph you find a lot of them. IMHO the
    best way would be to secure them all with a try/catch block - but there
    are really a lot of in this class and you will find more and more when
    you search in the hole Kettle project.

    Even when we fix this, some other developer can forget to secure new
    event listeners.

    Proposed patch:
    ---------------
    For the time beeing, I added a retry message box after a fatal error in
    the readAndDispatch() loop and allow to retry this loop.

    I tested this for exceptions in mousewheel and doubleclick and it works
    to retry and save the work. Kettle was very stable after this retry. I
    realized a performance impact in Eclipse after this, so keyboard and
    mouse events in Eclipse are slowed down.

    The message after a fatal error is (please see also attached picture):

    "You now have the possibility to continue working with Spoon and e.g.
    save your work (we propose to save as with a different name).

    Please consider that Spoon could be not stable after this fatal error.

    AND: Please help us in improving Kettle and file a bug report with as
    much details as possible to reproduce and fix this problem.

    Do you want to continue working with Spoon?"

    --> YES / NO

    Question to all:
    ----------------
    Do you think we need to secure all event listeners or do you think the
    "last mouse trap" solution mentioned above is enough. Or do you have any
    other idea?

    I filed a jira bug for this over here:
    http://jira.pentaho.com/browse/PDI-1279
    and hesitate to close this one as fixed (since it is more a
    circumvention) and want to get some feedback if we need to do the hole
    try/catch story or any other ideas come up.

    Thanks a lot & keep on hacking,
    Jens


    --~--~---------~--~----~------------~-------~--~----~
    You received this message because you are subscribed to the Google Groups "kettle-developers" group.
    To post to this group, send email to kettle-developers (AT) googlegroups (DOT) com
    To unsubscribe from this group, send email to kettle-developers-unsubscribe (AT) g...oups (DOT) com
    For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en
    -~----------~----~----~----~------~----~------~--~---

  2. #2
    Roland Bouman Guest

    Default Re: Avoid FBY (frustration by crash) and loss of design changes on UI exceptions

    Hi Jens, all,

    I probably have the least amount of insight in the PDI codebase so
    please understand that I am only expressing my general feeling - not a
    strong judgement at all.

    > When you look for example at TransGraph you find a lot of them. IMHO the
    > best way would be to secure them all with a try/catch block - but there
    > are really a lot of in this class and you will find more and more when
    > you search in the hole Kettle project.


    What does "secure" mean exactly? Would it mean that each catch block
    would get a real handler that is specific to each case? Or will a noop
    handler do?

    How hard is it to detect where the spots are that need this?

    > Even when we fix this, some other developer can forget to secure new
    > event listeners.


    This seems like something that need not have to be too difficult to
    handle. I mean, it would require some documentation, and of course
    code review. I guess that the amount of effort that would cost is
    again dependent on how difficult it is to detect a spot of code that
    needs this.

    > The message after a fatal error is (please see also attached picture):


    On the one hand, this message is better than crashing. As such I
    suppose it can't hurt too much in a development/beta release. However,
    the message does make me feel a bit like when I would be inside a
    train, and the traindriver would inform us over the intercom

    "Dear ladies and gentlemen. We have just been derailed. We suggest you
    get out now, and walk along the track until you see the next station.
    Alternatively, stay onboard but please realize that we may plunge into
    the canyon anytime now. Have a nice day."

    The problems with these types of messages is that the program clearly
    indicates that it is capable of detecting a fouled up situation, yet
    is unable to mend it. There may be good technical reasons for that,
    but it will make a bad impression on the end-user none the less. I'd
    hate to be a sales engineer or so running into this problem. "More so
    than a crash?", well, yes, more so than a crash. Why? Well, psychology
    I guess. When something crashes without message, there could be many
    causes. This message clearly indicates that the program should know
    better but doesn't.

    If you really want to use this workaround, do not offer the user to
    continue. Instead, do something like:

    "We're sorry but we've detected an unrecoverable error. Your work has
    been saved as xxx.bak. Press Yes to automatically report this bug.
    Kettle will close now"

    The "Yes" button can then attempt to email a bug report, or if that
    fails, write the bug report to file and ask the user to please open it
    and follow instructions to report the bug at some later time.

    > Question to all:
    > ----------------
    > Do you think we need to secure all event listeners or do you think the
    > "last mouse trap" solution mentioned above is enough. Or do you have any
    > other idea?


    Like I said I cannot judge the amount of effort involved, as I do not
    know what "secure" means exaclty and I also do not know how much
    effort is involved in detecting these spots of code.

    > I filed a jira bug for this over here:http://jira.pentaho.com/browse/PDI-1279
    > and hesitate to close this one as fixed (since it is more a
    > circumvention) and want to get some feedback if we need to do the hole
    > try/catch story or any other ideas come up.


    I hope this helps.
    Kind regards,

    Roland
    --~--~---------~--~----~------------~-------~--~----~
    You received this message because you are subscribed to the Google Groups "kettle-developers" group.
    To post to this group, send email to kettle-developers (AT) googlegroups (DOT) com
    To unsubscribe from this group, send email to kettle-developers-unsubscribe (AT) g...oups (DOT) com
    For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en
    -~----------~----~----~----~------~----~------~--~---

  3. #3
    Matt Casters Guest

    Default Re: Avoid FBY (frustration by crash) and loss of design changes on UI exceptions

    Although I like the idea in itself, I have to side with Roland on the message
    description.
    Is there any particular reason to kill the main display loop of Spoon anyway?
    Since these days, we're looking for "widget disposed error" exceptions mostly,
    Perhaps we can add a "[x] don't bother me again with this" check-box?

    Matt


    On Monday 26 May 2008 09:33:12 Roland Bouman wrote:
    > Hi Jens, all,
    >
    > I probably have the least amount of insight in the PDI codebase so
    > please understand that I am only expressing my general feeling - not a
    > strong judgement at all.
    >
    > > When you look for example at TransGraph you find a lot of them. IMHO the
    > > best way would be to secure them all with a try/catch block - but there
    > > are really a lot of in this class and you will find more and more when
    > > you search in the hole Kettle project.

    >
    > What does "secure" mean exactly? Would it mean that each catch block
    > would get a real handler that is specific to each case? Or will a noop
    > handler do?
    >
    > How hard is it to detect where the spots are that need this?
    >
    > > Even when we fix this, some other developer can forget to secure new
    > > event listeners.

    >
    > This seems like something that need not have to be too difficult to
    > handle. I mean, it would require some documentation, and of course
    > code review. I guess that the amount of effort that would cost is
    > again dependent on how difficult it is to detect a spot of code that
    > needs this.
    >
    > > The message after a fatal error is (please see also attached picture):

    >
    > On the one hand, this message is better than crashing. As such I
    > suppose it can't hurt too much in a development/beta release. However,
    > the message does make me feel a bit like when I would be inside a
    > train, and the traindriver would inform us over the intercom
    >
    > "Dear ladies and gentlemen. We have just been derailed. We suggest you
    > get out now, and walk along the track until you see the next station.
    > Alternatively, stay onboard but please realize that we may plunge into
    > the canyon anytime now. Have a nice day."
    >
    > The problems with these types of messages is that the program clearly
    > indicates that it is capable of detecting a fouled up situation, yet
    > is unable to mend it. There may be good technical reasons for that,
    > but it will make a bad impression on the end-user none the less. I'd
    > hate to be a sales engineer or so running into this problem. "More so
    > than a crash?", well, yes, more so than a crash. Why? Well, psychology
    > I guess. When something crashes without message, there could be many
    > causes. This message clearly indicates that the program should know
    > better but doesn't.
    >
    > If you really want to use this workaround, do not offer the user to
    > continue. Instead, do something like:
    >
    > "We're sorry but we've detected an unrecoverable error. Your work has
    > been saved as xxx.bak. Press Yes to automatically report this bug.
    > Kettle will close now"
    >
    > The "Yes" button can then attempt to email a bug report, or if that
    > fails, write the bug report to file and ask the user to please open it
    > and follow instructions to report the bug at some later time.
    >
    > > Question to all:
    > > ----------------
    > > Do you think we need to secure all event listeners or do you think the
    > > "last mouse trap" solution mentioned above is enough. Or do you have any
    > > other idea?

    >
    > Like I said I cannot judge the amount of effort involved, as I do not
    > know what "secure" means exaclty and I also do not know how much
    > effort is involved in detecting these spots of code.
    >
    > > I filed a jira bug for this over
    > > here:http://jira.pentaho.com/browse/PDI-1279 and hesitate to close this
    > > one as fixed (since it is more a
    > > circumvention) and want to get some feedback if we need to do the hole
    > > try/catch story or any other ideas come up.

    >
    > I hope this helps.
    > Kind regards,
    >
    > Roland
    >



    --
    Matt
    ____________________________________________
    Matt Casters
    Chief Data Integration - Kettle founder
    Pentaho, Open Source Business Intelligence
    http://www.pentaho.org -- mcasters (AT) pentaho (DOT) org
    Tel. +32 (0) 486 97 29 37

    --~--~---------~--~----~------------~-------~--~----~
    You received this message because you are subscribed to the Google Groups "kettle-developers" group.
    To post to this group, send email to kettle-developers (AT) googlegroups (DOT) com
    To unsubscribe from this group, send email to kettle-developers-unsubscribe (AT) g...oups (DOT) com
    For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en
    -~----------~----~----~----~------~----~------~--~---

  4. #4
    Jens Bleuel Guest

    Default Re: Avoid FBY (frustration by crash) and loss of design changes on UI exceptions

    > Is there any particular reason to kill the main display loop of Spoon
    anyway?

    It is killed "automatically" by any non catched exception in an event
    listener and thus Spoon crashes/ends. That's why I optionally start with
    a retry this main display loop (look at the changes to Spoon by
    PDI-1279, then it becomes more clear I guess.)

    I want to emphasize, what I see is that these problems are VERY RARE,
    but when they occur.... they are very annoying for the user.

    And: This display box ONLY comes up when these very rare problems of a
    total Spoon crash occurs, not at any error or exception. (I don't think
    the latest "Widget is disposed" errors crash Spoon, do they?)

    May be this relativates the impact of the dialog - but I like the
    feedback and change proposals.

    Cheers,
    Jens

    Matt Casters schrieb:
    >
    > Although I like the idea in itself, I have to side with Roland on the message
    > description.
    > Is there any particular reason to kill the main display loop of Spoon anyway?
    > Since these days, we're looking for "widget disposed error" exceptions mostly,
    > Perhaps we can add a "[x] don't bother me again with this" check-box?
    >
    > Matt
    >
    >
    > On Monday 26 May 2008 09:33:12 Roland Bouman wrote:
    >> Hi Jens, all,
    >>
    >> I probably have the least amount of insight in the PDI codebase so
    >> please understand that I am only expressing my general feeling - not a
    >> strong judgement at all.
    >>
    >>> When you look for example at TransGraph you find a lot of them. IMHO the
    >>> best way would be to secure them all with a try/catch block - but there
    >>> are really a lot of in this class and you will find more and more when
    >>> you search in the hole Kettle project.

    >> What does "secure" mean exactly? Would it mean that each catch block
    >> would get a real handler that is specific to each case? Or will a noop
    >> handler do?
    >>
    >> How hard is it to detect where the spots are that need this?
    >>
    >>> Even when we fix this, some other developer can forget to secure new
    >>> event listeners.

    >> This seems like something that need not have to be too difficult to
    >> handle. I mean, it would require some documentation, and of course
    >> code review. I guess that the amount of effort that would cost is
    >> again dependent on how difficult it is to detect a spot of code that
    >> needs this.
    >>
    >>> The message after a fatal error is (please see also attached picture):

    >> On the one hand, this message is better than crashing. As such I
    >> suppose it can't hurt too much in a development/beta release. However,
    >> the message does make me feel a bit like when I would be inside a
    >> train, and the traindriver would inform us over the intercom
    >>
    >> "Dear ladies and gentlemen. We have just been derailed. We suggest you
    >> get out now, and walk along the track until you see the next station.
    >> Alternatively, stay onboard but please realize that we may plunge into
    >> the canyon anytime now. Have a nice day."
    >>
    >> The problems with these types of messages is that the program clearly
    >> indicates that it is capable of detecting a fouled up situation, yet
    >> is unable to mend it. There may be good technical reasons for that,
    >> but it will make a bad impression on the end-user none the less. I'd
    >> hate to be a sales engineer or so running into this problem. "More so
    >> than a crash?", well, yes, more so than a crash. Why? Well, psychology
    >> I guess. When something crashes without message, there could be many
    >> causes. This message clearly indicates that the program should know
    >> better but doesn't.
    >>
    >> If you really want to use this workaround, do not offer the user to
    >> continue. Instead, do something like:
    >>
    >> "We're sorry but we've detected an unrecoverable error. Your work has
    >> been saved as xxx.bak. Press Yes to automatically report this bug.
    >> Kettle will close now"
    >>
    >> The "Yes" button can then attempt to email a bug report, or if that
    >> fails, write the bug report to file and ask the user to please open it
    >> and follow instructions to report the bug at some later time.
    >>
    >>> Question to all:
    >>> ----------------
    >>> Do you think we need to secure all event listeners or do you think the
    >>> "last mouse trap" solution mentioned above is enough. Or do you have any
    >>> other idea?

    >> Like I said I cannot judge the amount of effort involved, as I do not
    >> know what "secure" means exaclty and I also do not know how much
    >> effort is involved in detecting these spots of code.
    >>
    >>> I filed a jira bug for this over
    >>> here:http://jira.pentaho.com/browse/PDI-1279 and hesitate to close this
    >>> one as fixed (since it is more a
    >>> circumvention) and want to get some feedback if we need to do the hole
    >>> try/catch story or any other ideas come up.

    >> I hope this helps.
    >> Kind regards,
    >>
    >> Roland
    >>

    >
    >




    --~--~---------~--~----~------------~-------~--~----~
    You received this message because you are subscribed to the Google Groups "kettle-developers" group.
    To post to this group, send email to kettle-developers (AT) googlegroups (DOT) com
    To unsubscribe from this group, send email to kettle-developers-unsubscribe (AT) g...oups (DOT) com
    For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en
    -~----------~----~----~----~------~----~------~--~---

  5. #5
    Jens Bleuel Guest

    Default Re: Avoid FBY (frustration by crash) and loss of design changes on UI exceptions

    Hi Roland & all,

    thanks for the detailed feedback ;-)

    > What does "secure" mean exactly? Would it mean that each catch block
    > would get a real handler that is specific to each case? Or will a noop
    > handler do?


    When a noop handler means "no operation" (="eating exceptions") then
    this is what should absolutely been avoided, but a generalized ongoing
    with a non specific error dialog would be o.k.

    > How hard is it to detect where the spots are that need this?


    E.g. Search for "listener" in the code base and find if there is no
    try/catch block....

    >> Even when we fix this, some other developer can forget to secure new
    >> event listeners.

    >
    > This seems like something that need not have to be too difficult to
    > handle. I mean, it would require some documentation, and of course
    > code review. I guess that the amount of effort that would cost is
    > again dependent on how difficult it is to detect a spot of code that
    > needs this.


    I don't know of an automated way doing this, yet - and that is what we
    need to ensure.

    And... last but not least I keep in mind all the nice (and funny)
    comments of the dialog ;-)

    In general we have also consider the number of incidents by this (very
    low I guess but higher then a derail) and the effort we need to
    improve/avoid this.

    Thanks a lot for this & cheers,
    Jens

    >
    >> The message after a fatal error is (please see also attached picture):

    >
    > On the one hand, this message is better than crashing. As such I
    > suppose it can't hurt too much in a development/beta release. However,
    > the message does make me feel a bit like when I would be inside a
    > train, and the traindriver would inform us over the intercom
    >
    > "Dear ladies and gentlemen. We have just been derailed. We suggest you
    > get out now, and walk along the track until you see the next station.
    > Alternatively, stay onboard but please realize that we may plunge into
    > the canyon anytime now. Have a nice day."
    >
    > The problems with these types of messages is that the program clearly
    > indicates that it is capable of detecting a fouled up situation, yet
    > is unable to mend it. There may be good technical reasons for that,
    > but it will make a bad impression on the end-user none the less. I'd
    > hate to be a sales engineer or so running into this problem. "More so
    > than a crash?", well, yes, more so than a crash. Why? Well, psychology
    > I guess. When something crashes without message, there could be many
    > causes. This message clearly indicates that the program should know
    > better but doesn't.
    >
    > If you really want to use this workaround, do not offer the user to
    > continue. Instead, do something like:
    >
    > "We're sorry but we've detected an unrecoverable error. Your work has
    > been saved as xxx.bak. Press Yes to automatically report this bug.
    > Kettle will close now"
    >
    > The "Yes" button can then attempt to email a bug report, or if that
    > fails, write the bug report to file and ask the user to please open it
    > and follow instructions to report the bug at some later time.
    >
    >> Question to all:
    >> ----------------
    >> Do you think we need to secure all event listeners or do you think the
    >> "last mouse trap" solution mentioned above is enough. Or do you have any
    >> other idea?

    >
    > Like I said I cannot judge the amount of effort involved, as I do not
    > know what "secure" means exaclty and I also do not know how much
    > effort is involved in detecting these spots of code.
    >
    >> I filed a jira bug for this over here:http://jira.pentaho.com/browse/PDI-1279
    >> and hesitate to close this one as fixed (since it is more a
    >> circumvention) and want to get some feedback if we need to do the hole
    >> try/catch story or any other ideas come up.

    >
    > I hope this helps.
    > Kind regards,
    >
    > Roland
    > >

    >




    --~--~---------~--~----~------------~-------~--~----~
    You received this message because you are subscribed to the Google Groups "kettle-developers" group.
    To post to this group, send email to kettle-developers (AT) googlegroups (DOT) com
    To unsubscribe from this group, send email to kettle-developers-unsubscribe (AT) g...oups (DOT) com
    For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en
    -~----------~----~----~----~------~----~------~--~---

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.