Thank you. My main point is that I've been wandering extensively around
the node-verse for the past 6 weeks and this is the first time I've ever
seen a definitive statement that try/catch is actually safe in that (or a
similarly simple) context. What you say always made intuitive sense to me,
but it's a little daunting to run into the dire-sounding warning early on
in my excursions into node.
On Friday, January 3, 2014 12:15:15 PM UTC-5, Forrest L Norvell wrote:
>
> The distinction is that JSON.parse is synchronous, and thus try-catch
> works perfectly well with it. Also, as Isaac said months ago, try-catch
> starts to get iffy when code in the try block has multiple control-flow
> branches that could get skipped over by a throw. This way of using
> try-catch is simple and therefore safe.
>
> It's unfortunate that a built-in JavaScript function that performs I/O
> (deserialization / unmarshalling) doesn't follow node's I/O convention of
> using a callback, but more because it's inconsistent (and therefore
> confusing) than because it's dangerous. If you use JSON.parse the way you
> describe, it's the best way I know of to deal with that potential error.
>
> F
>
> On Friday, January 3, 2014, Jason Shinn wrote:
>
>> I'm resurrecting this discussion because it's the most useful deep
>> exploration at the top of Google's search results for why try-catch is
>> unsafe per the warning in node's documentation.
>>
>> I've been bothered by a seeming disconnect between that warning, stated
>> in absolute terms, and simple constructs like the following, which I see in
>> examples all over the place:
>>
>> try {
>> JSON.parse(mightNotBeValidJson);
>> }
>> catch (e) {
>> //whoops, it wasn't, but this is the only way I could know that without
>> using an entirely different parser that fails a little more gracefully
>> //further, I can handle the fact that it wasn't valid JSON without
>> nuking the current process from orbit, it's not the only way to be sure
>> }
>>
>> ... try/catch *can* be used in such situations without creating havoc,
>> can it not? I'm about 6 weeks into node, and I've mostly worked with that
>> assumption, but have continued to be bothered by the prohibition laid out
>> in the docs from trying to recover from such events.
>>
>> If my assumption is in fact correct, I think the statement that "it's
>> almost never safe" is a little far-reaching, and much more accurate to say
>> that it's very easy misuse, and is mostly appropriate when it contains code
>> that is strictly synchronous and where the resources and dependencies used
>> are well-known and simply managed. That is to say, a limited but extensive
>> subset of work done in node. Beyond that, let people dig their own holes,
>> this is programming, if we couldn't do anything dangerous it wouldn't be
>> any fun :)
>>
>> On Saturday, April 6, 2013 1:53:11 PM UTC-4, Isaac Schlueter wrote:
>>>
>>> On Fri, Apr 5, 2013 at 11:09 AM, Nicolas Grilly
>>> <[email protected]> wrote:
>>> > Does it mean that this paragraph of Node.js documentation about
>>> domains:
>>> >
>>> > "By the very nature of how throw works in JavaScript, there is almost
>>> never
>>> > any way to safely "pick up where you left off", without leaking
>>> references,
>>> > or creating some other sort of undefined brittle state."
>>> >
>>> > could be rewritten as is (without "in JavaScript"):
>>> >
>>> > "By the very nature of how throw works, there is almost never any way
>>> to
>>> > safely "pick up where you left off", without leaking references, or
>>> creating
>>> > some other sort of undefined brittle state."
>>>
>>> Yeah, probably, but I don't want to get into a whole big thing about
>>> how throws in Erlang or Haskell or Lisp are actually perfectly safe,
>>> or can be made safe in Clojure or Scala, or if only JavaScript had
>>> typed catches, we could do this or that. Ugh. Boring tedious useless
>>> discussions, those are.
>>>
>>> Node is for running JavaScript, so JavaScript's limitations are Node
>>> program limitations. *JavaScript* throws are fundamentally unsafe if
>>> they jump over a branch in the execution-flow graph. To the extent
>>> that "language X" is like JavaScript, it will be similarly unsafe.
>>> (Ruby and Python are both very similar to JavaScript - stateful,
>>> imperative, syntaxy, semi-functional, garbage collected.)
>>>
>> --
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "nodejs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
