🚀 go-pugleaf

For this particular problem, being the resetting of the cursor, I would
recommend a try-finally block. This does not necessarily replace the
functionality of destructors but it solves the problem you have.

Code Example is:

method() {

    Cursor oldCursor = getCursor();
    try {
       setCursor(Cursor.WAIT_CURSOR);
        // treatment
        if (some_condition) {
            return;
        } else {
            // more processing
        }

        return;
    } finally {
        setCursor(oldCursor);
    }
}

The absence of explicit destructors requires different object design and
analysis. You can always build an explicit call to a "cleanup" method. The
benefit of garbage collection and the reduction in memory errors, IMHO, out
weigh the costs.

++Evan


> method() {
>   Cursor oldCursor = getCursor();
>   setCursor(new Cursor(Cursor.WAIT_CURSOR));
>
>   // treatment ...
>
>   // everytime I come across a return in my algorithm, just before the
> return statement :
>   setCursor(oldCursor);
>
>   //..

> .}




Bruno Moncorg� wrote:

> I have a problem finding how to get around the limitation imposed by the
> absence of destructors in Java.
>
> The destructor in C++ was very useful to control not just deallocation
> (which is done automatically by the garbage collector in Java) but alse
> to restore a previous state when the state of something changes
> temporarily within a limited scope, the scope of a method for instance.
>
> Let me exemplify this :
>
> Suppose that I want to change the cursor of a frame during a certain
> operation and restore it to its previous state when I leave the method.
>
> What I will do in Java is :
>
> method() {
>   Cursor oldCursor = getCursor();
>   setCursor(new Cursor(Cursor.WAIT_CURSOR));
>
>   // treatment ...
>
>   // everytime I come across a return in my algorithm, just before the
> return statement :
>   setCursor(oldCursor);
>
>   //...
> }