Re: Plugins with GUI
Lew allegedly wrote:
That is a nice use of 'assert' and one I wouldn't have thought of.
It's a widely-ignored truism that software must be deployed to be
useful. It's hard to bridge deployment aspects to code; this use of
'assert' provides an elegant and sturdy bridge.
Daniele Futtorovic wrote:
Wait, wat?
This?
assert macroDelegate != null : "null delegate to process macro
" + macroName;
Yes. It *is* the sole and only use of 'assert' in the quoted post, so it
could hardly be anything else, could it?
How so?
First of all, let's restore the context. Roedy Green wrote:
final Macro macroDelegate =
LoadCodeToProcessMacro.getMacroProcessorInstance( macroName );
assert macroDelegate != null : "null delegate to process macro
" + macroName;
This is a pattern quite prevalent in dependency injection (DI), JNDI lookups,
JDBC connections and the like. The 'getFooInstance()' factory or declarative
equivalent pulls in some deployment-specific delegate or handler, just as in
this example, often specified in a resource file or deployment descriptor.
If that delegate is not correctly deployed or specified, you will get back a
'null' or throw an exception. (Something like this will usually be
exception-enforced.)
If there is an issue, this gets rectified pretty much once per deployment.
After that, it just works - the correct delegate is deployed where it belongs.
A check 'if ( macroDelegate == null )' at that point is not helpful. It's
just wasted cycles. A production instance can shut off 'assert' checking
(globally or just for the class), safe in the assertion that once fixed, the
problem is gone. Poof! No overhead.
If the problem recurs, turn on 'assert' and repeat. This should be rare.
So it's elegant - one small 'assert' prevents a raft of difficulties. It's
sturdy - you can guarantee success across a range of scenarios.
Q.E. effing D.
--
Lew
Ceci n'est pas une pipe.