Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25735

Re: Plugins with GUI

Show all headers | View raw

On Thu, 27 Jan 2011 01:53:13 +0100, Daniele Futtorovic
<da.futt.news@laposte.net.invalid> wrote, quoted or indirectly quoted
someone who said :

>On 27/01/2011 00:34, Lew allegedly wrote:
>> On 01/26/2011 05:22 PM, Daniele Futtorovic wrote:
>>> On 26/01/2011 21:12, Lew allegedly wrote:
>>>> 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.
>>>
>>> Hardly.
>>>
>>> You mention deployment. Either the producer of that code has control
>>> over the JVM parameters, or they haven't.
>>
>> They don't, but that's not the point.
>>
>> They know that the deployer has control, and can instrument the code,
>> with 'assert', for their use.
>>
>>> If they haven't, then they cannot assert that assertions are enabled.
>>
>> Nor need to.
>>
>>> If they have, then they can. But how do they switch them off if they're
>>
>> The ops personnel do that, duh.
>>
>>> switched on as part of deployment? If they're not switched off, they're
>>> no better than a check and a throw instruction. If they want to switch
>>
>> They are different from check and throw, neither better nor worse. The
>> purpose of exceptions differs from that of assertions.
>
>An assertion is nothing but a check and throw you can neatly turn off.
>
>
>>> them off after, say, the "tuning phase", then they need either some
>>> post-deployment intervention (and hence to exceed the scope you have
>>
>> Well, duh, again. That's my point - the ops personnel switch assertions
>> on and off according to need. Have them on the first day while you make
>> sure everything is in place, then turn them off when the configuration
>> is correct.
>>
>>> set), or a supplemental mechanism that turns them off based on some
>>> action of an admin -- some configuration utility for instance. How could
>>> that possibly be less a bloat that an added null check?
>>
>> It's not "bloat", since "bloat" is defined as excess code that doesn't
>> serve a purpose. This is a tiny injection of code that confirms the
>> presence of an algorithmic necessity. It's the exact opposite of "bloat".
>
>I accept that definition. Point granted.
>
>
>> As for your so-called "supplemental mechanism", I'm not positing any
>> mechanism beyond that provided by the JVM itself, which of course is
>> always under the control of an admin's actions. What else would it be?
>
>A UI for editing some kind of startup script or service definition, for 
>instance. But we digress.
>
>
>>> Furthermore, if what the service provider kind of code needs to succeed
>>> is dynamic, part of the environment, then I don't see at which point you
>>> could ever decide that the check isn't necessary anymore. The
>>> environment can change at any time, due to migrations, restores, updates
>>> or whatever.
>>
>> I'm not proposing that this technique, or any other, is universally
>> applicable. Like any other tool in the programmer's kit, it must be
>> considered within the boundaries of its use case. I spoke only of the
>> use case where the environmental configuration has roughly deployment
>> lifespan. You do speak of a different use case where the technique might
>> not apply so neatly.
>>
>>> In other words, the "assert" in this particular case is at best no
>>> better than an if, and at worst useless, in upon or after deployment.
>>
>> It is better than an 'if', in the first place because the overhead of
>> the 'if' can be eliminated by turning off 'assert', in the second
>> because 'assert' and 'if' serve different purposes. The 'if' would
>> enforce the invariant, the 'assert' proves it. Not the same.
>
>if + throw proves it too.
>
>
>> In the more conventional application of asserting algorithmic
>> invariants, you'll usually see both an 'if' and an 'assert'.
>>
>>> I would argue that "assert" is destined to enforce code invariants and
>>> is most useful during the development phase. It is especially useful at
>>
>> Also the troubleshooting phase in production when something goes wrong.
>> You can turn on 'assert' and see if an invariant broke.
>>
>> With this new application inspired by Roedy's example, you can also do
>> that with environmental invariants.
>>
>>> the boundaries of different components interacting with each other, to
>>> enforce component contracts (especially in light of possible future
>>> modifications of a component by cow-workers).
>>
>> Or now, in light of possible future modifications of a component's
>> environment.
>
>This is precisely what I don't agree with. I'm grateful that you express
>it so pointedly, as it allows us to focus the discussion.
>
>So how's what you're proposing going to play out?
>Our guys go to the client and install our app. They enable assertions,
>wiggle it a bit and, satisfied with what they see, switch them off and
>go home.
>Two weeks later, we get a call from the client about some obscure error
>message or stack trace in the log, or, far worse, a testimony to the
>effect that something just "doesn't work". And I'm supposed to tell
>them: "hey wait, please enable assertions, please put your _production
>system_ in a state I suspect is _broken_ (and how am I supposed to know
>that this broken state won't lead to the corruption of some persistent
>data?) and tell me if you see a big error message"?
>
>No. Bloody. Way. The app's environment, by definition, is something that
>is subject to change and outside of my control. If _my_ app makes
>assumptions with respects to its environment, and these assumptions
>don't hold, then I want it to *break reliably*.
>I'll often explicitly throw AssertionErrors in such cases. Yes, within
>an if block. I don't give a shit about that added JMP. It's well worth
>it and anyway I've already got those checks all over the place, whenever
>I manipulate arrays or in dozens of methods, many of which I'll have
>written myself.
>
>The assert functionality does not provide the kind of reliability I
>demand for that purpose. It is a very useful mechanism, but only before
>delivery, during development and integration.
>
>df.

This particular case, pretty much the same thing happens whether the
assert is enabled on not. You get an exception. The advantage of the
assert being turned on is the error message is a tad more helpful.

If an assert fails, presumably something is wrong with a program or
one of its resources -- not data input files and keyed input. That is
why it SHOULD be safe to turn it off for production.

Sometimes I catch myself using assert to detect flawed data.  There is
no way the compiler knows.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
To err is human, but to really foul things up requires a computer.
~ Farmer's Almanac
It is breathtaking how a misplaced comma in a computer program can
shred megabytes of data in seconds.

Back to comp.lang.java.programmer | Previous | Next | Find similar

Thread

Re: Plugins with GUI Roedy Green <see_website@mindprod.com.invalid> - 2011-02-02 07:04 -0800

csiph-web