How to handle "deprecated/avoided/hidden" functionality

Continuing the discussion from Classification of "features we don't think are a good way of coding anymore":

I’d err towards logging it, and probably display it in the debug output. Stuff that’s deprecated is - by definition(*) - still supposed to work as per normal, so not sure raising an exception if using a piece of deprecated functionality is that ideal.


Adam

(*) a definition. Possibly not your favourite one.

FWIW, Micha has already posted just as you suggest somewhere (I can’t find it though). So options were:

  • Do nothing
  • Log it
  • Throw error

OK, I’m good with those options.

Cheers for the clarification. Is there a Jira ticket covering this?


Adam

FWIW, what I generally did in FW/1, as part of the migration from 1.x to 2.x to 2.5 to 3.x was to:

  • declare a feature deprecated - in the documentation and in release notes / mailing list posts
  • introduce a setting to allow the feature, defaulted to “enabled”, sometimes with a warning log message to console
  • in the next version, change the setting to “disabled” by default, and throw an exception on use (and log to console on use if “enabled”)
  • in the next version, remove the feature altogether (and the setting)

I think that this is a good plan. the only thing I’d add to step one is to log usage of that feature.

in my applications I added a simple custom tag that’s called Deprecated, which logs an optional message and the stack trace to a log file named deprecated.

then going over the log file it’s easy to see where there is still old code that uses the deprecated feature and update it.

Yup, bullets 1 & 2 were “Step 1” since that happened in the same version – I just didn’t want a long, run-on sentence there.

ATM when a functionality is marked “as deprecated” this has no influence on the code executed.
The only influence is that this is shown in the documentation.
I would like to see the following functionality for this.
A switch in the admin with the following options:

How to handle if deprecated functionality is used?
(*) (default) do nothing
( ) show in debug output
( ) throw an exception

Writing it to log might be better (and more persistent) than just outputting it on the screen, yes?

could be a 4th option, maybe you could also choose more than one option (checkbox)

Good ideas.

maybe with an interface that allows to extend this, so if you wanna add a new behaviour in case a deprecated functionality is used, you simply add a component looking like this in a certain directory, this way you can add your custom behaviour.

Example for logging to a log file (simplified):

/**
* This component add a new "deprecated" behaviour to the engine, it logs to a log named "deprecated"
*/
component displayName="Logger" {
    public function getLabel(){// this is shown as a checkbox in the Lucee admin
        return "Log";
    }
    public function getDescription(){// this is shown as a checkbox in the Lucee admin
        return "Logs to a log file named deprecated.log";
    }

    /**
   * @name name of the functionality that is deprecated and used, for example "ListTrim"
   * @template file where the functionality is used.
   * @line line of the file where the functionality was used
    */
    public function onDeprecate(string name,string template, numeric line) localmode=true {// better name for this function?
        log file="deprecated.log" text="#name# was used in file #file# on line #line#";
      

 // you could even do things like
      msg="#name# was used in file #file# on line #line#";
      if(name=="listTrim") msg&=", use the function listCompat instead.";
      log file="deprecated.log" text="#msg#";
    } 
}

this way we have the complete logic in CFML, the java code only bind it to the core

1 Like

I’m all for this sort of approach to things in general. Second guessing some common use cases, but then exposing an interface for devs to handle things their own way as well.

Nice one.