StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I think when they said "<em>we are leaking resources</em>", they really meant "<em>we <strong>might</strong> be leaking resources</em>". If http.createServer handles exceptions appropriately, threads and sockets shouldn't be leaked. However, they certainly could be if it doesn't handle things properly. In the general case, you never <em>really</em> know if something handles errors properly all the time. </p> <p>I think they are wrong / very misleading when they said "<em>By the .. nature of how throw works in JavaScript, there is almost never any way to safely ...</em>" . There should not be anything about how throw works in Javascript (vs other languages) that makes it unsafe. There is also nothing about how throw/catch works in general that makes it unsafe - unless of course you use them wrong.</p> <p>What they should have said is that exceptional cases (regardless of whether or not exceptions are used) need to be handled appropriately. There are a few different categories to recognize:</p> <p>A. State</p> <ol> <li>Exceptions that occur while external state (database writing, file output, etc) is in a transient state</li> <li>Exceptions that occur while shared memory is in a transient state </li> <li>Exceptions where only local variables might be in a transient state</li> </ol> <p>B. Reversibility</p> <ol> <li>Reversible / revertible state (eg database rollbacks)</li> <li>Irreversible state (Lost data, unknown how to reverse, or prohibitive to reverse)</li> </ol> <p>C. Data criticality</p> <ol> <li>Data can be scrapped</li> <li>Data must be used (even if corrupted)</li> </ol> <p>Regardless of the type of state you're messing with, if you can reverse it, you should do that and you're set. The problem is irreversible state. If you can destroy the corrupted data (or quarantine it for separate inspection), that is the best move for irreversible state. This is done automatically for local variables when an exception is thrown, which is why exceptions excel at handling errors in purely functional code (ie functions with no possible side-effects). Likewise, any shared state or external state should be deleted if that's acceptable. In the case of shared state, either throw exceptions until that shared state becomes local state and is cleaned up by unrolling of the stack (either statically or via the GC), or restart the program (I've read people suggesting the use of something like nodejitsu forever). For external state, this is likely more complicated.</p> <p>The last case is when the data is critical. Well, then you're gonna have to live with the bugs you've created. Everyone has to deal with bugs, but its the worst when your bugs involve corrupted data. This will usually require manual intervention (reconstructing the lost/damaged data, selectively pruning, etc) - exception handling won't get you the whole way in the last case. </p> <p>I wrote a similar answer related to how to handle mid-operation failure in various cases in the context of multiple updates to some data storage: <a href="https://stackoverflow.com/a/28355495/122422">https://stackoverflow.com/a/28355495/122422</a></p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload