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]<javascript:_e({}, 'cvml', '[email protected]');>
> To unsubscribe from this group, send email to
> [email protected] <javascript:_e({}, 'cvml',
> 'nodejs%[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] <javascript:_e({}, 'cvml',
> 'nodejs%[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.
