I think {{issue && isue.value }} should work or?

Hi @miqmago,

catching the error silently would not be a good option, as it could lead to difficult to debug problems. You could avoid your issue using a condition, for instance you could do something like

[issue.value !== null] say i{{issue.value}}
[issue.value === null] do some other stuff

On the other hand, maybe it would be nice to have a kind of "onError" command, that allows you to define a fallback dialog when there is an unexpected error.

We had an other issue (think ws closed because inactivity in last cleanup) that ways exactly about the same and yes - question is what should happen if the replacement is not posible.

Alternaive to an "onError" could be to simply catch the error and do not replace the placeholder at all - yes people would maybe wonder why but would maybe be consistent

I see you point, but don't agree hiding errors is more consistent. If the developer is trying to use a variable to send a message to the user and that variable is not initialised, it can be intentional or not, we can't know.

Regarding the onError, in the meantime, the globalFallbackDialog setting is available in the bot, which allows you to set the name of the dialog to be executed in case of errors while processing the bot flow (defaults to '/globalFallbackDialog'). So this can be used in the meantime to catch errors; not the same behaviour, because it's global for the whole conversation flow, but still useful.

@aigloss so if I understood well, if I place a

dialog globalFallbackDialog
 say Something went really wrong, please contact someone

I would fallback there? By the name of the dialog I would'nt say it is an error dialog, is it configurable? Also I've searched in the whole node_modules/@nlpjs @4.22.0 for globalFallbackDialog but I couldn't find any reference.

On the other hand, maybe it would be nice to have a kind of "onError" command, that allows you to define a fallback dialog when there is an unexpected error.

I also think this could be a good option.

Currently I'm instantiating the bot like this:

        dock = await dockStart(JSON.parse(settings));
        registerValidators(dock);
        registerActions(dock);
        directline = dock.get('directline');
        apiServer = dock.get('api-server');
        contextManager = dock.get('context-manager');

        // Lo lanza el @nlpjs/nlp/src/context-manager.js::setContext
        contextManager.onCtxUpdate = async (context: IBotContext) => {
            // do some stuff
        };

Maybe this could be another possibility?:

    contextManager.onError = (context: IBotContext)  => {};

@Apollon77 @aigloss validation of any variable could be an option, but this would be a kind of silently let an error pass. In my case, the problem was that the variable was not set and I had to fix an action problem. If I would have prevented the error with variable validation, it could have lead to a bug deployment in productive in this case, so I'm not sure if this is the best option...

Hi @miqmago ,

have a look at

The name of the dialog is configurable in the bot configuration. Try updating your settings to include the following

{
    "settings": {
        ...
        "bot": {
            "globalFallbackDialog": "/myErrorDialog"
        }
    },
    "use": [...]
}

having that in place, the dialog myErrorDialog should be executed whenever there is an unexpected error

Ok I see, it's starting from v4.24.2... Will update, many thanks!!

If you are planning the onError feature I can keep this issue open.
If you agree I could do a pull request. I would do something like is:

  async process(session) {
    const context = await this.contextManager.getContext(session);
    try {
      context.channel = session.channel;
      // ...
    } catch(err) {
      if (typeof context.onError === 'function') {
        context.onError(err);
      }
      throw err;
    }
  }

So @aigloss, what do you think? Makes sense to add the try-catch to process and to call onError function when exists?