3 ms·

From the frontend perspective, isn't it sometimes ideal to use try/catch? Unfortunately with the fragmented browser implementations of HTML5 and JavaScript, so

by Bahamut 13y ago

From the frontend perspective, isn't it sometimes ideal to use try/catch? Unfortunately with the fragmented browser implementations of HTML5 and JavaScript, sometimes what is an exception in one browser is correct usage in another. It's a complex beast of a problem at times. Of course, you should be judicious in your usage of try/catch, since it's obviously something that can be abused very poorly.

potatolicious 13y ago
Unfortunately yeah - sometimes the brokenness of tr/catch you inherit from the platform level. Reminds me of when I was trying to write a Win8/Metro app for fun. Turns out in the particular network class I was using 404's throw exceptions. What a horrific design - 404 isn't an unexpected state at all, particularly when calling restful apis. But there we were, a pointless try/catch or nothing. A lot of the brokenness with exceptions is software that models expected operational state as exceptions.
- windowsworkstoo 13y ago
  Yes that was an issue with the old WebRequest classes, but now with System.Net.Http the situation is much better (though they did what most people end up doing and wrapping WebRequest in a sensible manner)
jakub_g 13y ago
Due to asynchronous nature of JavaScript it's basically impossible to use "one big try/catch". Code that is invoked via setTimeout executes with an empty stack so something like try { setTimeout(foo, 1000) } catch (ex) { ... } won't be caught here if foo throws. In some DOM APIs there are 'onerror' handlers (like XHR), in NodeJS the convention is to have an "error" first parameter in the callback (which is null if there's no error). Also try-catch generates additional scope object inside the catch clause hence it's a bit more expensive than just doing a function call. Generally try-catch makes sense in JavaScript only locally when executing some external synchronous code that is known to throw exceptions.

by Bahamut 13y ago

potatolicious 13y ago

Unfortunately yeah - sometimes the brokenness of tr/catch you inherit from the platform level. Reminds me of when I was trying to write a Win8/Metro app for fun. Turns out in the particular network class I was using 404's throw exceptions. What a horrific design - 404 isn't an unexpected state at all, particularly when calling restful apis. But there we were, a pointless try/catch or nothing. A lot of the brokenness with exceptions is software that models expected operational state as exceptions.

windowsworkstoo 13y ago
Yes that was an issue with the old WebRequest classes, but now with System.Net.Http the situation is much better (though they did what most people end up doing and wrapping WebRequest in a sensible manner)

jakub_g 13y ago

Due to asynchronous nature of JavaScript it's basically impossible to use "one big try/catch". Code that is invoked via setTimeout executes with an empty stack so something like try { setTimeout(foo, 1000) } catch (ex) { ... } won't be caught here if foo throws. In some DOM APIs there are 'onerror' handlers (like XHR), in NodeJS the convention is to have an "error" first parameter in the callback (which is null if there's no error). Also try-catch generates additional scope object inside the catch clause hence it's a bit more expensive than just doing a function call. Generally try-catch makes sense in JavaScript only locally when executing some external synchronous code that is known to throw exceptions.