A fix to make parse errors more visible

[gabrielg]

Right now, a lot of parsing errors are actually silently swallowed. This fixes that. Rather than add a new exception class, I modified the existing ParseError to just pass along the entire original exception - this means anyone actually using the ParseError for anything will have to slightly modify their code.

[cowboyd]

I have to say I agree with @abloom. I like the fact that the original ParseError had the same backtrace as the original error, this makes detecting where the error actually happened a snap. Is there any reason we can't have one change and not the other?

[gabrielg]

I mean, I'm stashing away the original exception - you just have to call '.original.backtrace' now instead. The other exceptions that Less.js can generate don't always have backtraces, as such. For example:

https://github.com/cloudhead/less.js/blob/master/lib/less/parser.js#L320 - creates a new LessError
https://github.com/cloudhead/less.js/blob/master/lib/less/parser.js#L233 - has what I assume is a backtrace as 'stack', but which I believe would be empty in this case

Basically, I was trying to keep the semantics of rescuing ParseError to catch parsing errors, and not having to special case on a V8 error with the expected properties, vs. something the Less.js parser can return in that callback that behaves differently.

[bradphelan]

+1 swallowing exceptions is not ideal. This error was raised on less-rails because of it.

metaskills/less-rails#21

[kares]

this one's a bit obsolete esp. since therubyrhino support - depends on the JS runtime how native exception are visible