Any form of reply on this question/problem would be highly appreciated. I believe this is a real use case and I'd like to know what other people think.
I've had to deal with this multiple times since I sent this to es-discuss. On Tue, Nov 5, 2013 at 5:39 PM, Benjamin (Inglor) Gruenbaum < [email protected]> wrote: > 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
