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] <javascript:>> 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.
