That's a good question. I try to discuss problems I run into. Developers, me included have found ways to minimize reliance on try/catch in synchronous operations using monadic maybies and checking values.
It's very often in JavaScript that I want to handle exceptions that are related to I/O and/or external resources. In JavaScript these operations are almost always asynchronous. It's very common to handle the issue of asynchronously handling exceptions using the mechanism that is used to wrap the asynchronous operation. - If it's a callback people typically use the `(err,` first parameter convention. - If it's a promise people use a "rejected" callback, a common (but not the prettiest) example is `.fail` in jQuery. Both these options don't suppress things like syntax errors, reference errors etc. There are of course other ways to do asynchronous operations and I/O but more generally, mechanisms that go around the language error handling constructs do a pretty good job at this. Generators give me a new great way to do concurrency, they reduce code and increase readability. However - they bring me back to the try/catch of the language which does not make the distinction or allow me address the issue without wrapping the catch with more code. On Tue, Nov 5, 2013 at 5:04 PM, Domenic Denicola < [email protected]> wrote: > I am curious what, if anything, about this problem has to do with > asynchronicity? That seems to be a key part of your point, but I don't > understand why you wouldn't phrase the problem entirely in terms of > synchronous operations since nothing seems unique to async. > > On 5 Nov 2013, at 09:48, "Benjamin (Inglor) Gruenbaum" <[email protected]> > wrote: > > Traditionally, JavaScript code contains some sort of asynchronous logic > either on the client side or on the server side. > > This makes the `try/catch` construct non-practical for many real use > cases because it can not catch errors caused by callbacks and/or other > asynchronous operations involved. This is why we have common idioms like > the `(err,result)` of NodeJS callbacks or reject in promises > implementations and so on. > > NodeJS also introduces domains which let you catch all errors that > originated from a piece of code in a certain way. > > ES6 Generators recently implemented in NodeJS allow us to do concurrency > using coroutines. This allows for very nice code that's very readable in > certain cases. The async_functions proposal is also very interesting > solving the problem without needing a "runner" for the generator. > > However, one issue arises from using generators for such concurrency. > The current way try/catch works with generators does not give us a way to > differentiate things like syntax errors from logic errors. > > Consider the following piece of code using Bluebird promises: > > ``` > Promise.coroutine(function *(){ > try{ > let db = yield DBEngine.open("northwind"); > let result = yield db.query("SELECT name FROM users") > return res; > } catch (e){ > //code to handle exception in DB > } > }); > ``` > Noticed the `ReferenceError`? Not obvious at first glance. A compile time > tool _might_ find it but I may have a closure variable named `res`. This > might even happen later when making changes. A catch-all does not do a good > job here. What I'd want to do is to catch all exceptions that are _mine_. I > need a way to catch exceptions of a different type. > > This is a real need in light of the new found usage for try/catch given > generators. > > I've looked around and found one possible solution using catch guards ( > http://wiki.ecmascript.org/doku.php?id=strawman:catch_guards ) , I know > Firefox supports catch guards but I was unable to find anything in the > specification or in the mailing list when searching relating to it. > > Petka added: > > Without predicated catch clauses you would need to write something like > this: > > ```js > Promise.coroutine(function *(){ > try{ > let db = yield DBEngine.open("northwind"); > let result = yield db.query("SELECT name FROM users") > return res; > } catch (e) { > if( e instanceof RejectionError ) { > //code to handle exception in DB > } > else { > throw e; > } > > } > }); > ``` > > The manual rethrow can easily be forgotten to be written > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
