try catch (e) -> log.debug "hides away" client handler code exceptions
See original GitHub issueThe 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.
Issue Analytics
- State:
- Created 7 years ago
- Comments:20 (15 by maintainers)
Top Results From Across the Web
Exceptional Logging of Exceptions in Python - Loggly
The pattern here is to optimistically execute some code—the call to find_burrito_joints() , in this case—within a try block. In the event a ......
Read more >C# Exception Handling Best Practices - Stackify Blog
Below is a simple example of a method that may throw an exception and how to properly use a try catch finally block...
Read more >What is a good way to pass useful state information to an ...
Put the message in the log and then rethrow the exception. Constructing Exceptions is expensive and can easily hide useful debugging ...
Read more >When do we really need try/catch? - Salesforce Stack Exchange
What the main point of try/catch? To catch and handle an exception. The handling is the key. What it means to handle an...
Read more >JavaScript's try-catch hid my bugs! - freeCodeCamp
So I put a few try-catch handlers inside the various methods being called, and added logging statements inside the catch block.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@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.
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).