Try/catch conditional exceptions in light of generators

[Benjamin Gruenbaum]

Hey, I just wanted to point out that this is now discussed in
https://github.com/groundwater/nodejs-symposiums/pull/5

It appears that there are no proposals on the way to deal with it and it is
a very real problem. What would be the correct process to bring more
attention to it?

On Fri, Nov 22, 2013 at 12:04 AM, Benjamin (Inglor) Gruenbaum <
inglor at gmail.com> wrote:

>
> 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/20160209/c1b435db/attachment.html>