How to fallback into error when reprompt is processed in Alexa Skill












1















I'm new to developing Alexa Skills. I'm working on a Skill for the Spanish store, so I'm using the es-ES voice. I use the Node.js ASK-SDK and I've come across this issue:



When I'm trying to develop a conversation with reprompt, if the user says gibberish, that shouldn't trigger any of my utterances, I expect to enter in the Error Handler, as it's the one with canHandle == true, but the actual result is that that gibberish is detected and sorted by Alexa as one of the correct utterances. I've seen that in en-US you have the AMAZON.Fallback to sort-of prevent this issue but as none of the Spanish SDK have this, how can I detect this?



I've upload a demo project to emulate this behaviour



You can try with this the workflow:




  • Start the Skill

  • The skill returns the "Number One" text and stays listening (as there's a reprompt)

  • You write number two

  • The skill returns the "Number Two" text and stays listening with another reprompt

  • You say gibberish, for example, "d" or "blah blah blah"

  • You are sorted on a apparently random utterance.


Here's an example of the JSON input for "blah blah blah"



{
"version": "1.0",
"session": {
"new": false,
"sessionId": "amzn1.echo-api.session.55b928a6-ecb2-4b55-857e-af6a76dee6fe",
"application": {
"applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
},
"user": {
"userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
}
},
"context": {
"System": {
"application": {
"applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
},
"user": {
"userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
},
"device": {
"deviceId": "amzn1.ask.device.AETBPXRLKFDMVR23WFUFQ3HOFTGHQDISLOQAPWS4BDBD4FAGXUKW2P56RJ3G74C75HG63MS52UV7KFYJAENEVT6VIRZUEKWCQQHNGV3FMP6BM3A5JZCUXH2LRYDHLQLBH5ABDJ7EYRWUI5532NYEZLUCYIGMRZCM2WKQ3XG6NX5VZPOELTKUO",
"supportedInterfaces": {}
},
"apiEndpoint": "https://api.eu.amazonalexa.com",
"apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRkMGI3ZmZkLWI0MDgtNDg5YS1hYjVlLWE3ZDdiOGQwNWRhMyIsImV4cCI6MTU0MjM1OTg1NCwiaWF0IjoxNTQyMzU2MjU0LCJuYmYiOjE1NDIzNTYyNTQsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUVUQlBYUkxLRkRNVlIyM1dGVUZRM0hPRlRHSFFESVNMT1FBUFdTNEJEQkQ0RkFHWFVLVzJQNTZSSjNHNzRDNzVIRzYzTVM1MlVWN0tGWUpBRU5FVlQ2VklSWlVFS1dDUVFITkdWM0ZNUDZCTTNBNUpaQ1VYSDJMUllESExRTEJINUFCREo3RVlSV1VJNTUzMk5ZRVpMVUNZSUdNUlpDTTJXS1EzWEc2Tlg1VlpQT0VMVEtVTyIsInVzZXJJZCI6ImFtem4xLmFzay5hY2NvdW50LkFGV1BPV0NSUVVMSFVWS1FUVFg3SklTM08yNjRDQ0hTVVk0TVBIQ1NKUzRMS0xRWDQ1WUFSSjY3TFRHSFBNUzdSV1VYVk5ZVVRYVDZKTVQzRElDVEw1WVo3UUhTTFozUUlIRUtEUDVZUlBMQ0FFRlhURDRCUlk2V0pJS0MzNlVPM1FVNEY1WDVCTEZBR1g2QzNLTjc2TVFKRVRPNVBZNkk2NUNWTk9GQlFMR05aM1A0WU40SU9MWUJDQzdOREdBUTZMRkFXTVdUS1Q2RFdRWSJ9fQ.H50aG2L-K_AH-vRQ4ueu6n8GY_3T14KVjJysJjpWaAJEMfVlkx6CNwnQjDQJZHd1GQ1UpqcT3AkpqGDg86Z2J50RDmRp5ScUqqMQu0ZjrCxG9hItwT02ca4wxEo_hFrMb5VTTgqSORbfgzmDHJMOVaWjb_zJAcAFCJrF3qxzYzEo-E2ptBdRb7xKY0y_3MisF302HTUiZC3uTiRvWxv3jMT0_vq9cXDoHOar_WDf7Q6afF4DrEj6naX_vRpHT-63nWug1TiKRaJY4sEEaTlX0BVDigJ7t1LuH76ULeDEpJrSNW3mQtrHqUCnFNRYe9_-ru-rf-NkMpotYE7glWNnZg"
},
"Viewport": {
"experiences": [
{
"arcMinuteWidth": 246,
"arcMinuteHeight": 144,
"canRotate": false,
"canResize": false
}
],
"shape": "RECTANGLE",
"pixelWidth": 1024,
"pixelHeight": 600,
"dpi": 160,
"currentPixelWidth": 1024,
"currentPixelHeight": 600,
"touch": [
"SINGLE"
]
}
},
"request": {
"type": "IntentRequest",
"requestId": "amzn1.echo-api.request.fef2e2fc-b404-4729-85b4-e8ced71b6ecd",
"timestamp": "2018-11-16T08:17:34Z",
"locale": "es-ES",
"intent": {
"name": "NumberTwoIntent",
"confirmationStatus": "NONE"
}
}
}


How can I prevent this? I'd expect to enter the error, as it's the only one handler that could return true for "blah blah blah" utterance and so, tell the user there's been an error for their speech, but as it's being classified on a utterance, it returns some information the user hasn't asked for.



Thank you










share|improve this question





























    1















    I'm new to developing Alexa Skills. I'm working on a Skill for the Spanish store, so I'm using the es-ES voice. I use the Node.js ASK-SDK and I've come across this issue:



    When I'm trying to develop a conversation with reprompt, if the user says gibberish, that shouldn't trigger any of my utterances, I expect to enter in the Error Handler, as it's the one with canHandle == true, but the actual result is that that gibberish is detected and sorted by Alexa as one of the correct utterances. I've seen that in en-US you have the AMAZON.Fallback to sort-of prevent this issue but as none of the Spanish SDK have this, how can I detect this?



    I've upload a demo project to emulate this behaviour



    You can try with this the workflow:




    • Start the Skill

    • The skill returns the "Number One" text and stays listening (as there's a reprompt)

    • You write number two

    • The skill returns the "Number Two" text and stays listening with another reprompt

    • You say gibberish, for example, "d" or "blah blah blah"

    • You are sorted on a apparently random utterance.


    Here's an example of the JSON input for "blah blah blah"



    {
    "version": "1.0",
    "session": {
    "new": false,
    "sessionId": "amzn1.echo-api.session.55b928a6-ecb2-4b55-857e-af6a76dee6fe",
    "application": {
    "applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
    },
    "user": {
    "userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
    }
    },
    "context": {
    "System": {
    "application": {
    "applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
    },
    "user": {
    "userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
    },
    "device": {
    "deviceId": "amzn1.ask.device.AETBPXRLKFDMVR23WFUFQ3HOFTGHQDISLOQAPWS4BDBD4FAGXUKW2P56RJ3G74C75HG63MS52UV7KFYJAENEVT6VIRZUEKWCQQHNGV3FMP6BM3A5JZCUXH2LRYDHLQLBH5ABDJ7EYRWUI5532NYEZLUCYIGMRZCM2WKQ3XG6NX5VZPOELTKUO",
    "supportedInterfaces": {}
    },
    "apiEndpoint": "https://api.eu.amazonalexa.com",
    "apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRkMGI3ZmZkLWI0MDgtNDg5YS1hYjVlLWE3ZDdiOGQwNWRhMyIsImV4cCI6MTU0MjM1OTg1NCwiaWF0IjoxNTQyMzU2MjU0LCJuYmYiOjE1NDIzNTYyNTQsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUVUQlBYUkxLRkRNVlIyM1dGVUZRM0hPRlRHSFFESVNMT1FBUFdTNEJEQkQ0RkFHWFVLVzJQNTZSSjNHNzRDNzVIRzYzTVM1MlVWN0tGWUpBRU5FVlQ2VklSWlVFS1dDUVFITkdWM0ZNUDZCTTNBNUpaQ1VYSDJMUllESExRTEJINUFCREo3RVlSV1VJNTUzMk5ZRVpMVUNZSUdNUlpDTTJXS1EzWEc2Tlg1VlpQT0VMVEtVTyIsInVzZXJJZCI6ImFtem4xLmFzay5hY2NvdW50LkFGV1BPV0NSUVVMSFVWS1FUVFg3SklTM08yNjRDQ0hTVVk0TVBIQ1NKUzRMS0xRWDQ1WUFSSjY3TFRHSFBNUzdSV1VYVk5ZVVRYVDZKTVQzRElDVEw1WVo3UUhTTFozUUlIRUtEUDVZUlBMQ0FFRlhURDRCUlk2V0pJS0MzNlVPM1FVNEY1WDVCTEZBR1g2QzNLTjc2TVFKRVRPNVBZNkk2NUNWTk9GQlFMR05aM1A0WU40SU9MWUJDQzdOREdBUTZMRkFXTVdUS1Q2RFdRWSJ9fQ.H50aG2L-K_AH-vRQ4ueu6n8GY_3T14KVjJysJjpWaAJEMfVlkx6CNwnQjDQJZHd1GQ1UpqcT3AkpqGDg86Z2J50RDmRp5ScUqqMQu0ZjrCxG9hItwT02ca4wxEo_hFrMb5VTTgqSORbfgzmDHJMOVaWjb_zJAcAFCJrF3qxzYzEo-E2ptBdRb7xKY0y_3MisF302HTUiZC3uTiRvWxv3jMT0_vq9cXDoHOar_WDf7Q6afF4DrEj6naX_vRpHT-63nWug1TiKRaJY4sEEaTlX0BVDigJ7t1LuH76ULeDEpJrSNW3mQtrHqUCnFNRYe9_-ru-rf-NkMpotYE7glWNnZg"
    },
    "Viewport": {
    "experiences": [
    {
    "arcMinuteWidth": 246,
    "arcMinuteHeight": 144,
    "canRotate": false,
    "canResize": false
    }
    ],
    "shape": "RECTANGLE",
    "pixelWidth": 1024,
    "pixelHeight": 600,
    "dpi": 160,
    "currentPixelWidth": 1024,
    "currentPixelHeight": 600,
    "touch": [
    "SINGLE"
    ]
    }
    },
    "request": {
    "type": "IntentRequest",
    "requestId": "amzn1.echo-api.request.fef2e2fc-b404-4729-85b4-e8ced71b6ecd",
    "timestamp": "2018-11-16T08:17:34Z",
    "locale": "es-ES",
    "intent": {
    "name": "NumberTwoIntent",
    "confirmationStatus": "NONE"
    }
    }
    }


    How can I prevent this? I'd expect to enter the error, as it's the only one handler that could return true for "blah blah blah" utterance and so, tell the user there's been an error for their speech, but as it's being classified on a utterance, it returns some information the user hasn't asked for.



    Thank you










    share|improve this question



























      1












      1








      1


      1






      I'm new to developing Alexa Skills. I'm working on a Skill for the Spanish store, so I'm using the es-ES voice. I use the Node.js ASK-SDK and I've come across this issue:



      When I'm trying to develop a conversation with reprompt, if the user says gibberish, that shouldn't trigger any of my utterances, I expect to enter in the Error Handler, as it's the one with canHandle == true, but the actual result is that that gibberish is detected and sorted by Alexa as one of the correct utterances. I've seen that in en-US you have the AMAZON.Fallback to sort-of prevent this issue but as none of the Spanish SDK have this, how can I detect this?



      I've upload a demo project to emulate this behaviour



      You can try with this the workflow:




      • Start the Skill

      • The skill returns the "Number One" text and stays listening (as there's a reprompt)

      • You write number two

      • The skill returns the "Number Two" text and stays listening with another reprompt

      • You say gibberish, for example, "d" or "blah blah blah"

      • You are sorted on a apparently random utterance.


      Here's an example of the JSON input for "blah blah blah"



      {
      "version": "1.0",
      "session": {
      "new": false,
      "sessionId": "amzn1.echo-api.session.55b928a6-ecb2-4b55-857e-af6a76dee6fe",
      "application": {
      "applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
      },
      "user": {
      "userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
      }
      },
      "context": {
      "System": {
      "application": {
      "applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
      },
      "user": {
      "userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
      },
      "device": {
      "deviceId": "amzn1.ask.device.AETBPXRLKFDMVR23WFUFQ3HOFTGHQDISLOQAPWS4BDBD4FAGXUKW2P56RJ3G74C75HG63MS52UV7KFYJAENEVT6VIRZUEKWCQQHNGV3FMP6BM3A5JZCUXH2LRYDHLQLBH5ABDJ7EYRWUI5532NYEZLUCYIGMRZCM2WKQ3XG6NX5VZPOELTKUO",
      "supportedInterfaces": {}
      },
      "apiEndpoint": "https://api.eu.amazonalexa.com",
      "apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRkMGI3ZmZkLWI0MDgtNDg5YS1hYjVlLWE3ZDdiOGQwNWRhMyIsImV4cCI6MTU0MjM1OTg1NCwiaWF0IjoxNTQyMzU2MjU0LCJuYmYiOjE1NDIzNTYyNTQsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUVUQlBYUkxLRkRNVlIyM1dGVUZRM0hPRlRHSFFESVNMT1FBUFdTNEJEQkQ0RkFHWFVLVzJQNTZSSjNHNzRDNzVIRzYzTVM1MlVWN0tGWUpBRU5FVlQ2VklSWlVFS1dDUVFITkdWM0ZNUDZCTTNBNUpaQ1VYSDJMUllESExRTEJINUFCREo3RVlSV1VJNTUzMk5ZRVpMVUNZSUdNUlpDTTJXS1EzWEc2Tlg1VlpQT0VMVEtVTyIsInVzZXJJZCI6ImFtem4xLmFzay5hY2NvdW50LkFGV1BPV0NSUVVMSFVWS1FUVFg3SklTM08yNjRDQ0hTVVk0TVBIQ1NKUzRMS0xRWDQ1WUFSSjY3TFRHSFBNUzdSV1VYVk5ZVVRYVDZKTVQzRElDVEw1WVo3UUhTTFozUUlIRUtEUDVZUlBMQ0FFRlhURDRCUlk2V0pJS0MzNlVPM1FVNEY1WDVCTEZBR1g2QzNLTjc2TVFKRVRPNVBZNkk2NUNWTk9GQlFMR05aM1A0WU40SU9MWUJDQzdOREdBUTZMRkFXTVdUS1Q2RFdRWSJ9fQ.H50aG2L-K_AH-vRQ4ueu6n8GY_3T14KVjJysJjpWaAJEMfVlkx6CNwnQjDQJZHd1GQ1UpqcT3AkpqGDg86Z2J50RDmRp5ScUqqMQu0ZjrCxG9hItwT02ca4wxEo_hFrMb5VTTgqSORbfgzmDHJMOVaWjb_zJAcAFCJrF3qxzYzEo-E2ptBdRb7xKY0y_3MisF302HTUiZC3uTiRvWxv3jMT0_vq9cXDoHOar_WDf7Q6afF4DrEj6naX_vRpHT-63nWug1TiKRaJY4sEEaTlX0BVDigJ7t1LuH76ULeDEpJrSNW3mQtrHqUCnFNRYe9_-ru-rf-NkMpotYE7glWNnZg"
      },
      "Viewport": {
      "experiences": [
      {
      "arcMinuteWidth": 246,
      "arcMinuteHeight": 144,
      "canRotate": false,
      "canResize": false
      }
      ],
      "shape": "RECTANGLE",
      "pixelWidth": 1024,
      "pixelHeight": 600,
      "dpi": 160,
      "currentPixelWidth": 1024,
      "currentPixelHeight": 600,
      "touch": [
      "SINGLE"
      ]
      }
      },
      "request": {
      "type": "IntentRequest",
      "requestId": "amzn1.echo-api.request.fef2e2fc-b404-4729-85b4-e8ced71b6ecd",
      "timestamp": "2018-11-16T08:17:34Z",
      "locale": "es-ES",
      "intent": {
      "name": "NumberTwoIntent",
      "confirmationStatus": "NONE"
      }
      }
      }


      How can I prevent this? I'd expect to enter the error, as it's the only one handler that could return true for "blah blah blah" utterance and so, tell the user there's been an error for their speech, but as it's being classified on a utterance, it returns some information the user hasn't asked for.



      Thank you










      share|improve this question
















      I'm new to developing Alexa Skills. I'm working on a Skill for the Spanish store, so I'm using the es-ES voice. I use the Node.js ASK-SDK and I've come across this issue:



      When I'm trying to develop a conversation with reprompt, if the user says gibberish, that shouldn't trigger any of my utterances, I expect to enter in the Error Handler, as it's the one with canHandle == true, but the actual result is that that gibberish is detected and sorted by Alexa as one of the correct utterances. I've seen that in en-US you have the AMAZON.Fallback to sort-of prevent this issue but as none of the Spanish SDK have this, how can I detect this?



      I've upload a demo project to emulate this behaviour



      You can try with this the workflow:




      • Start the Skill

      • The skill returns the "Number One" text and stays listening (as there's a reprompt)

      • You write number two

      • The skill returns the "Number Two" text and stays listening with another reprompt

      • You say gibberish, for example, "d" or "blah blah blah"

      • You are sorted on a apparently random utterance.


      Here's an example of the JSON input for "blah blah blah"



      {
      "version": "1.0",
      "session": {
      "new": false,
      "sessionId": "amzn1.echo-api.session.55b928a6-ecb2-4b55-857e-af6a76dee6fe",
      "application": {
      "applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
      },
      "user": {
      "userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
      }
      },
      "context": {
      "System": {
      "application": {
      "applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
      },
      "user": {
      "userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
      },
      "device": {
      "deviceId": "amzn1.ask.device.AETBPXRLKFDMVR23WFUFQ3HOFTGHQDISLOQAPWS4BDBD4FAGXUKW2P56RJ3G74C75HG63MS52UV7KFYJAENEVT6VIRZUEKWCQQHNGV3FMP6BM3A5JZCUXH2LRYDHLQLBH5ABDJ7EYRWUI5532NYEZLUCYIGMRZCM2WKQ3XG6NX5VZPOELTKUO",
      "supportedInterfaces": {}
      },
      "apiEndpoint": "https://api.eu.amazonalexa.com",
      "apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRkMGI3ZmZkLWI0MDgtNDg5YS1hYjVlLWE3ZDdiOGQwNWRhMyIsImV4cCI6MTU0MjM1OTg1NCwiaWF0IjoxNTQyMzU2MjU0LCJuYmYiOjE1NDIzNTYyNTQsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUVUQlBYUkxLRkRNVlIyM1dGVUZRM0hPRlRHSFFESVNMT1FBUFdTNEJEQkQ0RkFHWFVLVzJQNTZSSjNHNzRDNzVIRzYzTVM1MlVWN0tGWUpBRU5FVlQ2VklSWlVFS1dDUVFITkdWM0ZNUDZCTTNBNUpaQ1VYSDJMUllESExRTEJINUFCREo3RVlSV1VJNTUzMk5ZRVpMVUNZSUdNUlpDTTJXS1EzWEc2Tlg1VlpQT0VMVEtVTyIsInVzZXJJZCI6ImFtem4xLmFzay5hY2NvdW50LkFGV1BPV0NSUVVMSFVWS1FUVFg3SklTM08yNjRDQ0hTVVk0TVBIQ1NKUzRMS0xRWDQ1WUFSSjY3TFRHSFBNUzdSV1VYVk5ZVVRYVDZKTVQzRElDVEw1WVo3UUhTTFozUUlIRUtEUDVZUlBMQ0FFRlhURDRCUlk2V0pJS0MzNlVPM1FVNEY1WDVCTEZBR1g2QzNLTjc2TVFKRVRPNVBZNkk2NUNWTk9GQlFMR05aM1A0WU40SU9MWUJDQzdOREdBUTZMRkFXTVdUS1Q2RFdRWSJ9fQ.H50aG2L-K_AH-vRQ4ueu6n8GY_3T14KVjJysJjpWaAJEMfVlkx6CNwnQjDQJZHd1GQ1UpqcT3AkpqGDg86Z2J50RDmRp5ScUqqMQu0ZjrCxG9hItwT02ca4wxEo_hFrMb5VTTgqSORbfgzmDHJMOVaWjb_zJAcAFCJrF3qxzYzEo-E2ptBdRb7xKY0y_3MisF302HTUiZC3uTiRvWxv3jMT0_vq9cXDoHOar_WDf7Q6afF4DrEj6naX_vRpHT-63nWug1TiKRaJY4sEEaTlX0BVDigJ7t1LuH76ULeDEpJrSNW3mQtrHqUCnFNRYe9_-ru-rf-NkMpotYE7glWNnZg"
      },
      "Viewport": {
      "experiences": [
      {
      "arcMinuteWidth": 246,
      "arcMinuteHeight": 144,
      "canRotate": false,
      "canResize": false
      }
      ],
      "shape": "RECTANGLE",
      "pixelWidth": 1024,
      "pixelHeight": 600,
      "dpi": 160,
      "currentPixelWidth": 1024,
      "currentPixelHeight": 600,
      "touch": [
      "SINGLE"
      ]
      }
      },
      "request": {
      "type": "IntentRequest",
      "requestId": "amzn1.echo-api.request.fef2e2fc-b404-4729-85b4-e8ced71b6ecd",
      "timestamp": "2018-11-16T08:17:34Z",
      "locale": "es-ES",
      "intent": {
      "name": "NumberTwoIntent",
      "confirmationStatus": "NONE"
      }
      }
      }


      How can I prevent this? I'd expect to enter the error, as it's the only one handler that could return true for "blah blah blah" utterance and so, tell the user there's been an error for their speech, but as it's being classified on a utterance, it returns some information the user hasn't asked for.



      Thank you







      alexa alexa-skills-kit alexa-skill






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 16 '18 at 12:01









      Kerberos

      2,71722545




      2,71722545










      asked Nov 16 '18 at 8:19









      RodrigoRodrigo

      313219




      313219
























          2 Answers
          2






          active

          oldest

          votes


















          2














          The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.



          So overall the recommendation is to:




          1. Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent


          2. Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)


          3. If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails


          4. Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this


          5. You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it


          6. Do not rely on catch all handlers (canHandle() set to always return true) to help you with this. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent. Similarly, do not rely on an ErrorHandler added via addErrorHandlers() as it will only trigger is there's an actual error in the code which is not inside a try/catch



          As soon as Amazon.FallbackIntent becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them






          share|improve this answer

































            2














            Since there is no AMAZON.FallbackIntent Alexa always tries to map it to the closest intent.



            ErrorHandler is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers) that can fulfil the request. Do not get confused between ErrorHandlers and UnhandledIntentHandlers. ErrorHandlers are for handling errors and UnhandledIntentHandler are/should be an IntentHandler for handling unhandled intents.



            In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler is never called.



            Since AMAZON.Fallback cannot be used, try these:



            1. Validating slots:

            Consider the following utterance:



            [BuyProductIntent]
            Utterances:
            I want a large pizza
            give me a large pizza


            which can be changed to



            I want a {size} {product}
            give me a {size} {product}


            where



            size-> regular, medium, large
            product->pizza, burger


            Now whenever your backend receives an BuyProductIntent request, validate the slots and respond with appropriate message. If some how BuyProductIntent is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.



            "Sorry, I didn't understand. Do you want to order pizza"


            This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.



            2. Add an OutOfDomainIntent

            Create an OutOfDomainIntent and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.






            share|improve this answer





















            • 1





              Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.

              – German
              Nov 17 '18 at 23:01








            • 2





              @German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message "message":"Could not find handler that can handle the request" and "name":"AskSdk.DefaultRequestDispatcher Error". As you said, the way I described ErrorHandler looked more like an UnhandledIntentHandler. Thanks for pointing it out, I will update.

              – Cicil Thomas
              Nov 18 '18 at 6:53






            • 1





              Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent

              – German
              Nov 18 '18 at 16:08






            • 1





              @German I have updated my answer. So unhandled intents should not be handled by an ErrorHandler, instead they should be handled by an IntentHandler itself. Thanks for the info.

              – Cicil Thomas
              Nov 18 '18 at 16:58











            • That's exactly right Cicil, thx again

              – German
              Nov 18 '18 at 19:58











            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53333910%2fhow-to-fallback-into-error-when-reprompt-is-processed-in-alexa-skill%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2














            The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.



            So overall the recommendation is to:




            1. Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent


            2. Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)


            3. If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails


            4. Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this


            5. You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it


            6. Do not rely on catch all handlers (canHandle() set to always return true) to help you with this. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent. Similarly, do not rely on an ErrorHandler added via addErrorHandlers() as it will only trigger is there's an actual error in the code which is not inside a try/catch



            As soon as Amazon.FallbackIntent becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them






            share|improve this answer






























              2














              The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.



              So overall the recommendation is to:




              1. Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent


              2. Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)


              3. If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails


              4. Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this


              5. You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it


              6. Do not rely on catch all handlers (canHandle() set to always return true) to help you with this. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent. Similarly, do not rely on an ErrorHandler added via addErrorHandlers() as it will only trigger is there's an actual error in the code which is not inside a try/catch



              As soon as Amazon.FallbackIntent becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them






              share|improve this answer




























                2












                2








                2







                The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.



                So overall the recommendation is to:




                1. Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent


                2. Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)


                3. If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails


                4. Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this


                5. You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it


                6. Do not rely on catch all handlers (canHandle() set to always return true) to help you with this. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent. Similarly, do not rely on an ErrorHandler added via addErrorHandlers() as it will only trigger is there's an actual error in the code which is not inside a try/catch



                As soon as Amazon.FallbackIntent becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them






                share|improve this answer















                The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.



                So overall the recommendation is to:




                1. Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent


                2. Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)


                3. If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails


                4. Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this


                5. You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it


                6. Do not rely on catch all handlers (canHandle() set to always return true) to help you with this. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent. Similarly, do not rely on an ErrorHandler added via addErrorHandlers() as it will only trigger is there's an actual error in the code which is not inside a try/catch



                As soon as Amazon.FallbackIntent becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Jan 10 at 9:45

























                answered Nov 17 '18 at 23:51









                GermanGerman

                7,40642947




                7,40642947

























                    2














                    Since there is no AMAZON.FallbackIntent Alexa always tries to map it to the closest intent.



                    ErrorHandler is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers) that can fulfil the request. Do not get confused between ErrorHandlers and UnhandledIntentHandlers. ErrorHandlers are for handling errors and UnhandledIntentHandler are/should be an IntentHandler for handling unhandled intents.



                    In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler is never called.



                    Since AMAZON.Fallback cannot be used, try these:



                    1. Validating slots:

                    Consider the following utterance:



                    [BuyProductIntent]
                    Utterances:
                    I want a large pizza
                    give me a large pizza


                    which can be changed to



                    I want a {size} {product}
                    give me a {size} {product}


                    where



                    size-> regular, medium, large
                    product->pizza, burger


                    Now whenever your backend receives an BuyProductIntent request, validate the slots and respond with appropriate message. If some how BuyProductIntent is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.



                    "Sorry, I didn't understand. Do you want to order pizza"


                    This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.



                    2. Add an OutOfDomainIntent

                    Create an OutOfDomainIntent and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.






                    share|improve this answer





















                    • 1





                      Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.

                      – German
                      Nov 17 '18 at 23:01








                    • 2





                      @German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message "message":"Could not find handler that can handle the request" and "name":"AskSdk.DefaultRequestDispatcher Error". As you said, the way I described ErrorHandler looked more like an UnhandledIntentHandler. Thanks for pointing it out, I will update.

                      – Cicil Thomas
                      Nov 18 '18 at 6:53






                    • 1





                      Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent

                      – German
                      Nov 18 '18 at 16:08






                    • 1





                      @German I have updated my answer. So unhandled intents should not be handled by an ErrorHandler, instead they should be handled by an IntentHandler itself. Thanks for the info.

                      – Cicil Thomas
                      Nov 18 '18 at 16:58











                    • That's exactly right Cicil, thx again

                      – German
                      Nov 18 '18 at 19:58
















                    2














                    Since there is no AMAZON.FallbackIntent Alexa always tries to map it to the closest intent.



                    ErrorHandler is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers) that can fulfil the request. Do not get confused between ErrorHandlers and UnhandledIntentHandlers. ErrorHandlers are for handling errors and UnhandledIntentHandler are/should be an IntentHandler for handling unhandled intents.



                    In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler is never called.



                    Since AMAZON.Fallback cannot be used, try these:



                    1. Validating slots:

                    Consider the following utterance:



                    [BuyProductIntent]
                    Utterances:
                    I want a large pizza
                    give me a large pizza


                    which can be changed to



                    I want a {size} {product}
                    give me a {size} {product}


                    where



                    size-> regular, medium, large
                    product->pizza, burger


                    Now whenever your backend receives an BuyProductIntent request, validate the slots and respond with appropriate message. If some how BuyProductIntent is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.



                    "Sorry, I didn't understand. Do you want to order pizza"


                    This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.



                    2. Add an OutOfDomainIntent

                    Create an OutOfDomainIntent and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.






                    share|improve this answer





















                    • 1





                      Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.

                      – German
                      Nov 17 '18 at 23:01








                    • 2





                      @German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message "message":"Could not find handler that can handle the request" and "name":"AskSdk.DefaultRequestDispatcher Error". As you said, the way I described ErrorHandler looked more like an UnhandledIntentHandler. Thanks for pointing it out, I will update.

                      – Cicil Thomas
                      Nov 18 '18 at 6:53






                    • 1





                      Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent

                      – German
                      Nov 18 '18 at 16:08






                    • 1





                      @German I have updated my answer. So unhandled intents should not be handled by an ErrorHandler, instead they should be handled by an IntentHandler itself. Thanks for the info.

                      – Cicil Thomas
                      Nov 18 '18 at 16:58











                    • That's exactly right Cicil, thx again

                      – German
                      Nov 18 '18 at 19:58














                    2












                    2








                    2







                    Since there is no AMAZON.FallbackIntent Alexa always tries to map it to the closest intent.



                    ErrorHandler is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers) that can fulfil the request. Do not get confused between ErrorHandlers and UnhandledIntentHandlers. ErrorHandlers are for handling errors and UnhandledIntentHandler are/should be an IntentHandler for handling unhandled intents.



                    In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler is never called.



                    Since AMAZON.Fallback cannot be used, try these:



                    1. Validating slots:

                    Consider the following utterance:



                    [BuyProductIntent]
                    Utterances:
                    I want a large pizza
                    give me a large pizza


                    which can be changed to



                    I want a {size} {product}
                    give me a {size} {product}


                    where



                    size-> regular, medium, large
                    product->pizza, burger


                    Now whenever your backend receives an BuyProductIntent request, validate the slots and respond with appropriate message. If some how BuyProductIntent is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.



                    "Sorry, I didn't understand. Do you want to order pizza"


                    This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.



                    2. Add an OutOfDomainIntent

                    Create an OutOfDomainIntent and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.






                    share|improve this answer















                    Since there is no AMAZON.FallbackIntent Alexa always tries to map it to the closest intent.



                    ErrorHandler is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers) that can fulfil the request. Do not get confused between ErrorHandlers and UnhandledIntentHandlers. ErrorHandlers are for handling errors and UnhandledIntentHandler are/should be an IntentHandler for handling unhandled intents.



                    In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler is never called.



                    Since AMAZON.Fallback cannot be used, try these:



                    1. Validating slots:

                    Consider the following utterance:



                    [BuyProductIntent]
                    Utterances:
                    I want a large pizza
                    give me a large pizza


                    which can be changed to



                    I want a {size} {product}
                    give me a {size} {product}


                    where



                    size-> regular, medium, large
                    product->pizza, burger


                    Now whenever your backend receives an BuyProductIntent request, validate the slots and respond with appropriate message. If some how BuyProductIntent is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.



                    "Sorry, I didn't understand. Do you want to order pizza"


                    This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.



                    2. Add an OutOfDomainIntent

                    Create an OutOfDomainIntent and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Nov 18 '18 at 16:48

























                    answered Nov 16 '18 at 12:47









                    Cicil ThomasCicil Thomas

                    3,39121633




                    3,39121633








                    • 1





                      Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.

                      – German
                      Nov 17 '18 at 23:01








                    • 2





                      @German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message "message":"Could not find handler that can handle the request" and "name":"AskSdk.DefaultRequestDispatcher Error". As you said, the way I described ErrorHandler looked more like an UnhandledIntentHandler. Thanks for pointing it out, I will update.

                      – Cicil Thomas
                      Nov 18 '18 at 6:53






                    • 1





                      Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent

                      – German
                      Nov 18 '18 at 16:08






                    • 1





                      @German I have updated my answer. So unhandled intents should not be handled by an ErrorHandler, instead they should be handled by an IntentHandler itself. Thanks for the info.

                      – Cicil Thomas
                      Nov 18 '18 at 16:58











                    • That's exactly right Cicil, thx again

                      – German
                      Nov 18 '18 at 19:58














                    • 1





                      Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.

                      – German
                      Nov 17 '18 at 23:01








                    • 2





                      @German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message "message":"Could not find handler that can handle the request" and "name":"AskSdk.DefaultRequestDispatcher Error". As you said, the way I described ErrorHandler looked more like an UnhandledIntentHandler. Thanks for pointing it out, I will update.

                      – Cicil Thomas
                      Nov 18 '18 at 6:53






                    • 1





                      Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent

                      – German
                      Nov 18 '18 at 16:08






                    • 1





                      @German I have updated my answer. So unhandled intents should not be handled by an ErrorHandler, instead they should be handled by an IntentHandler itself. Thanks for the info.

                      – Cicil Thomas
                      Nov 18 '18 at 16:58











                    • That's exactly right Cicil, thx again

                      – German
                      Nov 18 '18 at 19:58








                    1




                    1





                    Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.

                    – German
                    Nov 17 '18 at 23:01







                    Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.

                    – German
                    Nov 17 '18 at 23:01






                    2




                    2





                    @German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message "message":"Could not find handler that can handle the request" and "name":"AskSdk.DefaultRequestDispatcher Error". As you said, the way I described ErrorHandler looked more like an UnhandledIntentHandler. Thanks for pointing it out, I will update.

                    – Cicil Thomas
                    Nov 18 '18 at 6:53





                    @German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message "message":"Could not find handler that can handle the request" and "name":"AskSdk.DefaultRequestDispatcher Error". As you said, the way I described ErrorHandler looked more like an UnhandledIntentHandler. Thanks for pointing it out, I will update.

                    – Cicil Thomas
                    Nov 18 '18 at 6:53




                    1




                    1





                    Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent

                    – German
                    Nov 18 '18 at 16:08





                    Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent

                    – German
                    Nov 18 '18 at 16:08




                    1




                    1





                    @German I have updated my answer. So unhandled intents should not be handled by an ErrorHandler, instead they should be handled by an IntentHandler itself. Thanks for the info.

                    – Cicil Thomas
                    Nov 18 '18 at 16:58





                    @German I have updated my answer. So unhandled intents should not be handled by an ErrorHandler, instead they should be handled by an IntentHandler itself. Thanks for the info.

                    – Cicil Thomas
                    Nov 18 '18 at 16:58













                    That's exactly right Cicil, thx again

                    – German
                    Nov 18 '18 at 19:58





                    That's exactly right Cicil, thx again

                    – German
                    Nov 18 '18 at 19:58


















                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53333910%2fhow-to-fallback-into-error-when-reprompt-is-processed-in-alexa-skill%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Bressuire

                    Vorschmack

                    Quarantine