Matt Kruse

Did you try defining app.error? That allows you to handle the exceptions however you wish. Otherwise, they are silently eaten to prevent the exception from bubbling up and potentially crashing...

You can trap and throw an exception if you want: // Log and throw intent exceptions app.error = function(e,request,response) { console.log(e); throw e; }; The reason I trap errors is...

For that case, yes, I can see how you would prefer no default error handling. In my case, I'm imagining running a container for Alexa apps, and I never want...

I agree that it's discouraged if you catch your own errors. The difference here is that I am enabling developers to handle the caught exception. So it's not flow control,...

I'm still torn on this. In theory, I agree with you. I'd prefer to throw the exception by default, unless the user defines some special handling. But I think the...

This is a great improvement. I'm trying to add a Dialog to a skill right now and finding that I need the exact changes in this PR. This should be...

I use my own helper function that I call within the app: ``` var has_display = function(request) { try { return !!request.data.context.System.device.supportedInterfaces.Display; } catch(e) { return false; } }; ```...

I already have helper functions like these and many more in my local version of this lib, I just find the structure and tests required in the release version to...

You can use session attributes for this. Each intent could call a common function to check to see if category is set in session, and if not, prompt the user...

Comment added on the PR. Merge and release soon?