Hi.. I'm prototyping an automated javascript validation tool based on
Rhino.. hence a theoretical question: would it be possible to get the
following patch accepted to Rhino main branch (anyway.. are the actual
developers of Rhino also on this list..? I assume yes..)
ok, the idea is that you have a nice interface ErrorReporter through which
all the parsing/evaluating exceptions/errors are reported (nice design,
btw:). What is happening currently is:
1) Main#exec sets the errorReporter:
errorReporter = new ToolErrorReporter(false, global.getErr());
shellContextFactory.setErrorReporter(errorReporter);
2) Main#processOptions(String[] ) processes the command line arguments and
adds them to context.
3) CompilerEnvirons#initFromContext(Context cx) initializes the compiler
environment through which the errorReporter reference is propagated:
setErrorReporter(cx.getErrorReporter());
I wonder if a snippet could be added to Main#processOptions so that a custom
implementation of ErrorReporter could be provided? So basically if i would
write something like:
java -classpath /path/to/rhino/js.jar:/path/to/my-error-reporter.jar
org.mozilla.javascript.tools.shell.Main
--error-reporter=my.custom.ErrorReporter /path/to/scripts/myScript.js
.. then the processOptions would basically do something like this ..
setErrorReporter(Class.forName("my.custom.ErrorReporter").getConstructor().newInstance());
.. and now i could do whatever i want with the errors (parse them, report
them, gather statistics)?
Okay... this probably sounds too hackish.. some cleaner solution could be
thought of. But *theoretically*... is it just a little bit probable that
this kind of pluggability could be added if I provide a clean solution? I
could of course always go and fork rhino or instrument the bytecode or stuff
like that.. yeah maybe that's even easier. What do you think?
Thanks!
Sander
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
