Any concrete benefits of extra level of indirection

Question

Please consider the Javascript code excerpt at the bottom. Roughly it consists of two modules, one for handling messages. What is the benefit of the filtersUpdateSuccess method within the messages module?

Currently it merely delegates to the overwriteAll method of the tplPanels module. One idea that strikes me is that within the filtersUpdateSuccess method, the call to tplPanels.overwriteAll could be wrapped in a try/catch. Could this benefit me, and are there any other benefits to the extra level of indirection?

PS .... I am familiar with the following question and have consulted it and followed the links within it, but now I want an answer in a specific context as opposed to the more general: Level of Indirection solves every Problem

function msgHandlers() {
    var scope
        ,msgs;

    return {
        SET_CONTEXT: function(context) {
            scope = context.scope;
            msgs = context.messages;
        }

        ,SUBSCRIBE_ALL: function() {
            me.subscribe(scope, msgs.FILTERS_UPDATE_SUCCESS, this.filtersUpdateSuccess);
            //me.subscribe(scope, msgs.FILTERS_UPDATE_SUCCESS, tpl.overwriteAll);
        }

        ,filtersUpdateSuccess: function(filterValues) {
            tplPanels().overwriteAll(filterValues);
        }
    }
}

function tplPanels() {
    var instances = {};

    return {
        locationInstance: function() {
            if (!instances.locationPanel) {
                instances.locationPanel = locationPanel();
            }
            return instances.locationPanel;
        }
        //more instances, etcetera
        ,overwriteAll: function(filterValues) {
            //do something useful
        }
    }
        //etcetera

Answer 1

The case here seems to be one of abstraction of interface, not extra layers of reference indirection.

Interface abstraction serves several purposes:

1. To cause a piece of code to fit an interface required by one generic client or one client whose shape is out of your control.
2. To cause a piece of code to fit an interface shared by multiple clients.
3. To cause a piece of code to fit a maintainer's mental model by abstracting away implementation details.
4. To cause a piece of code to fit an interface required by a planned (not just possible) future use-case.

If another module in your system already takes different inputs with the context-setting-subscribing-filtering interface then it can be valuable because it allows your code to plug in there: (1) or (2) above.

If you have concreate plans to have multiple providers or consumers of this interface, then it can be valuable to just make it conform to the interface now since you've already done the work to page the code into memory: (4) above.

If other modules are already structured this way, or if filtering is a common operation other modules use, then code maintainers can leverage that to learn your code quickly: (3) above.

If none of those apply, then, since filtersUpdateSuccess doesn't close over anything that tplPanels doesn't, there's no value in the interface abstraction.