Updating in try/finally

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Updating in try/finally

Rob Eden
Hi guys -

I think there's a pretty serious problem with usage of the  
ListEventAssembler. The main problem I've encountered is that calls  
to beginEvent()/commitEvent() are almost never in try/finally blocks.  
The problem that occurs is that an exception that occurs during an  
event will cause the list to be completely unusable.

As an example, take a look at FilterList.listChanged(). If an  
exception is ever thrown, say, during matching... the list can never  
be used again because it will think it's mid-event. Granted, throwing  
the exception is bad, but I think GlazedLists should handle it better  
and would if the commitEvent() was in a finally block.

What do you guys think? Does that sound reasonable?

Rob

--

"Let your heart soar as high as it will.
  Refuse to be average."
                            - A. W. Tozer


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Updating in try/finally

Jesse Wilson-2
Hey Rob ---

Recovering from programmer errors is a difficult task.
Whenever a Matcher or Comparator throws a RuntimeException,
that's a programmer error and I think that our priorities should be:
1. Tell the programmer about their error. The only way
     to do this that is loud enough is rethrowing the Exception
2. Maintain a consistent state in the EventList itself.
    What does this mean if we can't get a true/false answer
    from a Matcher or a sort order from a Comparator? Perhaps
    a good approach would be to do the safest thing possible in such a
    case, such as replacing a broken Matcher with the TrueMatcher
    on failure, or a broken Comparator with the null Comparator.

Currently we're only doing #1, but I agree that it's reasonable
for us to do #2 as well, just as long as we continue to do #1.
Would you mind adding a bug to our defect database to manage
this enhancement?

Cheers,
Jesse

On 8/12/05, Rob Eden <[hidden email]> wrote:

> Hi guys -
>
> I think there's a pretty serious problem with usage of the
> ListEventAssembler. The main problem I've encountered is that calls
> to beginEvent()/commitEvent() are almost never in try/finally blocks.
> The problem that occurs is that an exception that occurs during an
> event will cause the list to be completely unusable.
>
> As an example, take a look at FilterList.listChanged(). If an
> exception is ever thrown, say, during matching... the list can never
> be used again because it will think it's mid-event. Granted, throwing
> the exception is bad, but I think GlazedLists should handle it better
> and would if the commitEvent() was in a finally block.
>
> What do you guys think? Does that sound reasonable?
>
> Rob
>
> --
>
> "Let your heart soar as high as it will.
>   Refuse to be average."
>                             - A. W. Tozer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Updating in try/finally

kkoster
Any movement on this issue? I see this is still a problem. If an invalid operation is attempted on a list (e.g. setting and entry with a negative index), the internal state of the ListEventAssembler becomes inconsistent (i.e. the allowNestedEvents flag is never reset to true) and further operations that depend on this fail.