Generally you should avoid double negative testing which I think is what
would happen here...
*Scenario 1:*
boolean shouldShutdown = shutdown();
if (shouldShutdown) {
System.exit(0);
}
*Scenario 2:*
boolean dontShutdown = shutdown();
if (!dontShutdown) { // double negative
System.exit(0)
}
I think Scenario 1 is easier to understand.
Alternatively why not return an enum?
public enum ShutdownResponse { CONTINUE, ABORT };
And change the signature to:
public ShutdownResponse shutdown();
Cheers,
Chris
2009/6/24 Greg Brown <[email protected]>
> Most of the time my applications don't have any shutdown logic. So the
>> shutdown() method is already a corner case.
>>
>
> Actually, most of our sample applications do. They close the main window,
> perform service logout, etc.
>
> there are going to be times when the program does not have a
>> choice about shutting down (e.g. System Update forced a reboot).
>> Thus we need to separate the "can shutdown" flag from the "shutting down
>> now" action.
>>
>
> That's why shutdown() takes a boolean "optional" argument. If optional is
> true, the method can return a value indicating whether it would like to
> cancel shutdown. If false (e.g. during reboot), the return value will be
> ignored.
>
> I think the method signatures as currently defined are OK. They parallel
> (somewhat) the applet lifecycle methods. My question to you all was - should
> the return value of shutdown() mean "approve" or "deny"? It is currently
> defined as "approve", but I'm leaning towards changing it to the latter.
>
>
>
>
