[Improvement] Suggest a try-catch handler for the SOLWriter

[teward]

Given the issues seen in #62, and that being the call stack issue, I would like to make a suggestion for better code handling here.

We know from my experimentation that Chrome has a small call stack cap (65535). We also know that RangeErrors are thrown here.

NOTE: All lines of code extracted from Minerva were obtained from the Chrome or Firefox developer consoles while tracing the execution and error progression of the Minerva application.

This line of code, when the Array ends up having a total number of elements larger than the call stack, is what throws the RangeError that I've observed in #62 (note that I'm going to work with non-minified code hereon in this post):

c = Array.apply([], c);

We can probably improve here by adding an error handler, which then uses a more useful error message (again, not minified), which captures the very specific RangeError being seen in these cases about the call stack being exceeded, and then generating our own RangeError message which provides more useful reporting of the core issue (and though the new RangeError is uncaught intentionally so it's reported to the end user, it's got more useful data here):

try {
    c = Array.apply(p[,c);
}
catch (err): {
    if (err.name == 'RangeError' && err.message == "Maximum call stack size exceeded") {
        throw RangeError("Too many elements in SOL file to process in your current browser.");
    }
    else {
        throw err;
    }
}

This is useful for two reasons:

1. From what I can tell, the only time RangeError: Maximum call stack size exceeded is getting thrown with the call stack error being observed is when the array length is larger than the cap in the browser. We capture the RangeError, and then redefine its error message by throwing our own RangeError, with a customized error message indicating the core problem that it is too large to be processed by Minerva in the current browser.
2. For any and all other types of errors, they remain unhandled and unchanged; we are only implementing a change for the one specific case observed so far.

---

Feel free to reject this, but it may be better to print a more useful error than just "maximum call stack size exceeded" for this case.

[gmariani]

I've added the try/catch although it looks like the bug has been fixed in Chrome 56+. This will be in v4.2.0

[gmariani]

4.2.0 is now live