try catch (e) -> log.debug "hides away" client handler code exceptions

The Connection class silently “consumes” any exceptions in a passed handler code. This is unexpected and hard to debug.

self._session.onjoin = function (details) {
    if (self.onopen) {
        try {
            self.onopen(self._session, details);
        } catch (e) {
            log.debug("Exception raised from app code while firing Connection.onopen()", e);
        }
    }
};

Suggest to change it to log.error() or similar.

[pjanik]

@oberstet, I know. But let me ask how does this piece of code relate to the mentioned article?

IMHO it’s just very opinionated decision to swallow my exception and optionally log it (only if DEBUG flag is turned on). I think it’s is really strange pattern.

If I comment out this try-catch block, application crashes when my code throws an exception and I can see see the call stack. For me this is definitely expected behaviour. I should handle my exceptions and if not - crash. It’s pretty weird that external library wraps my code in big try-catch block and don’t let my app crash. If I wanted to do it, I would just add similar try-catch block inside my handler.

[oberstet]

Regarding differentiating the source of the error (onopen, onclose, “on event”, “on call”, “on progress” handlers), we could use different exception types, but always fire the same “on user error” optional callable on the connection object.

Advantage would be: this is approach stays within the design as currently in AutobahnPython (where above differentation is missing, but could be added too of course).