Lucee 6, better cftry and cfdocument

[Zackster]

yeah, let’s overload every tag with 1000 different features isn’t that the unix philosophy?

[BK_BK]

@dawesi : You can do DTAP perfectly well with systems not operational in other stages.

Sure thing. The key is to ensure that:

…whatever is in the production environment has already been tested, tried out and accepted in the preceding DTA phase. The idea is to avoid surprises in production.

@dawesi : Do i not test my facebook posting feature as the linked in server is down during testing? both use the same part of my app (the social posting feature)?

Sure thing. The key is to ensure that:

…whatever is in the production environment has already been tested, tried out and accepted in the preceding DTA phase. The idea is to avoid surprises in production.

@dawesi : That said my comment doesn’t change DTAP, it’s purely a config option for monolithic systems that rely in some parts on 2ndary systems, there is many reasons to run different code for different environments (aka config files).

Sure thing. The key is to ensure that …

[BK_BK]

@Zackster : yeah, let’s overload every tag with 1000 different features isn’t that the unix philosophy?

Zac, you can’t blame people for trying. Lucee is based in Switzerland, home of the many-faceted army knife.

[Zackster]

I think these discussions are really great

I’m an aussie, we only need one big knife

[Roberto_Marzialetti]

@Zackster

yeah, let’s overload every tag with 1000 different features isn’t that the unix philosophy?

I was actually thinking of proposing the same thing for cfdocument.
(indeed, now I change the title of the post).

Because often, during development, you have to comment cfdocument (and all cfdocumentitem and cfdocumentsection) to see the generated output directly on the html.

And that’s really boring.

[BK_BK]

I would argue that code that has been commented out is not actually code comment. It is clutter.
Code comment is comment on active - that is, running - code.

But a developer may have good reason to hold on to commented-out code. That is where version management comes in handy. For example, code that is active in one version of the software could be commented out - that is, completely absent - from a second version.

[dawesi]

@BK_BK

Zac, you can’t blame people for trying. Lucee is based in Switzerland, home of the many-faceted army knife.

Agree, and this is far from that case. I think Zac’s assumption we’re adding 1000’s of things, when we’re adding TWO is over the top and doesn’t help the discussion either way (for or against)

yet we have datasource but not mailsource… there’s plenty of room for ‘common sense’ additions to tags/functions

I think in this case it makes sense though. it’s easy to understand. I dont see the need to add extra tags when existing ones could clearly fit the bill.

[dawesi]

I still think your point is not valid this use case. You dont bring a knife to a gun fight. (as CD found out in CD2)

@Zackster

I’m an aussie, we only need one big knife

I’m also an Aussie and that knife you refer to also probably has a bottle opener on it #lol

[dawesi]

I think both of us have valid points and you can argue both ways equally.

I guess that’s the beauty of development there is no one perfect (or really one ‘universal’ standard) way to do it well, (and every few years someone invents a new one) and especially when dealing with super funds, banks, telcos and alike you can NEVER test every integration LIVE in dev/staging. It’s just unrealistic. You either have to mock it or gracefully degrade that function, either way DTAP is somewhat useless to these and many orgs because of this.

[AdamCameron]

@dawesi

there’s plenty of room for ‘common sense’ additions to tags/functions

I think in this case it makes sense though. it’s easy to understand. I dont see the need to add extra tags when existing ones could clearly fit the bill.

I agree that Zac employing the “slippery slope” logical fallacy is unhelpful (as was all the Crocodile Dundee stuff, although it made me chuckle).

However I contest that this is a “‘common sense’ additions to tags/functions”. I don’t think you’ve met that burden yet.

Also this is interesting: “I dont see the need to add extra tags”. Well quite. Why add try disabled=true when you could just stick a rethrow at the top of the catch? Or change the catch (any e) to catch (AnythingElse e). You have yet to explain why this new feature is an improvement on any existing strategy to arrive at the same end.

I would also like to see a precedent of this sort of thing being implemented in any other language…

[AdamCameron]

@dawesi

@AdamCameron

I also suspect it’s an enabler for ppl who don’t write tests;

Where is is solved in your view? (trying to understand the use-case you assume)

I do not understand the question, sorry. I understand the sequence of words, but I do not know why you chose that sequence of words to reply to the comment of mine you have quoted.

[Roberto_Marzialetti]

@FKL

<cftry> 
    <cf_doSomething>

    <cfcatch type="never_mind">
       <cfabort>
    </cfcatch>
</cftry>

how can I pass the “type” argument in cfscript?
with the “name” argument (according to the documentation) I get an error.

same for:

catch( name="e" ); 
catch( type="fake" ); 
catch( name="e", type="typeFake" ); 
catch( e, "typeFake" );

[Julian_Halliwell]

@Roberto_Marzialetti

how can I pass the “type” argument in cfscript?

try{
    x = y
}
catch( expression exception ){
    dump( exception.type ) // "expression"
}

[FKL]

@Roberto_Marzialetti

how can I pass the “type” argument in cfscript?

try {
  a = 1/0;
} catch(LeaveMeAloneException ex) {
  writeOutput("This line will never be executed.");
}

[Zackster]

Lucee 6.0.0.534 just got the ability to nest thrown exceptions, with a new clause attribute/argument

LDEV-438 Allow exceptions to be nested

<cfthrow message="shit happens!" cause="#exceptionObjOrCFCatchBlock#">