Here's how I see this post:

    - Performing Evented I/O well is one of the biggest use cases of
JavaScript - in the browser, in mobile apps, on the server and generally.
    - Exceptions in I/O scenarios did not traditionally post a problem
since constructs like callbacks and promises were used.
    - Generators were introduced in ES6, allowing developers like me to
write code without needing many of those constructs. This fundamentally
changes the way I can write JavaScript.
    - With generators, I can write try/catch clauses using the native
language syntax. That's nice.
    - Try/catch clauses don't have any form of guards in ES, meaning I
can't really catch logic errors and syntax reference/errors differently in
a nice way. When adding I/O errors to the mix the problem gets magnified
times 100 as my first example shows.

I'm not even saying I think `catch(e if` is the solution. I'm not saying I
have a solution I'm content with. I'm not even saying I have a solution at
all. If it sounds like I was saying "everyone should just implement catch..
if right way" then I apologize for that and it wasn't my intent.

This is why I posted:

   - Hey, I'm having the issue, are you having it too? Is it a real problem?
   - If so, are there clever ways to deal with it?
   - If so, what are they, are there proposals on the way?
   - If so, since this is an important issue to me, how can I promote it
being addressed?

I think that the first of these has been established, there was a
suggestion raised about the third and I have no idea about the fourth. I do
however, admit that the patterns proposal doesn't sound to me like it has
enough to solve this use case, or that I understand how the two are that
connected (which is what I tried saying in that post).













On Thu, Nov 21, 2013 at 11:34 PM, Jason Orendorff <jason.orendorff at gmail.com
> wrote:

> On Thu, Nov 21, 2013 at 12:55 PM, Brendan Eich <brendan at mozilla.com>
> wrote:
> > So, we need the well-championed, thought-through, pattern-matching
> proposal
> > first. It won't take too long, I bet, and in any event you are *not*
> going
> > to get browsers implementing catch-if quickly -- I am 100% sure of this,
> > based on long experience.
>
> And amen to that.
>
> Benjamin, adding one language feature for every reasonable use case
> presented on es-discuss sounds like a great way to get a language full
> of incoherent hacks in a hurry. That is, I don't think you'd like the
> result you're asking for, if you just directly extrapolate that to
> everyone else's JS pain point that can be addressed with one tiny
> leetle waffer-thin bit of syntax.
>
> A platform can have a hundred thousand APIs. A programming language
> can't have a hundred thousand features. The complexity budget is
> finite. We've got to add language features that work in multiple
> syntactic contexts and support multiple use cases.
>
> -j
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131122/2da5d177/attachment.html>

Here's how I see this post:

- Performing Evented I/O well is one of the biggest use cases of JavaScript - in the browser, in mobile apps, on the server and generally.
- Exceptions in I/O scenarios did not traditionally post a problem
since constructs like callbacks and promises were used.
- Generators were introduced in ES6, allowing developers like me to
write code without needing many of those constructs. This fundamentally
changes the way I can write JavaScript.
- With generators, I can write try/catch clauses using the native
language syntax. That's nice.
- Try/catch clauses don't have any form of guards in ES, meaning I
can't really catch logic errors and syntax reference/errors differently in
a nice way. When adding I/O errors to the mix the problem gets magnified
times 100 as my first example shows.

I'm not even saying I think `catch(e if` is the solution. I'm not saying I
have a solution I'm content with. I'm not even saying I have a solution at
all. If it sounds like I was saying "everyone should just implement catch..
if right way" then I apologize for that and it wasn't my intent.

This is why I posted:

- Hey, I'm having the issue, are you having it too? Is it a real problem?
- If so, are there clever ways to deal with it?
- If so, what are they, are there proposals on the way?
- If so, since this is an important issue to me, how can I promote it
being addressed?

I think that the first of these has been established, there was a
suggestion raised about the third and I have no idea about the fourth. I do
however, admit that the patterns proposal doesn't sound to me like it has
enough to solve this use case, or that I understand how the two are that
connected (which is what I tried saying in that post).