应显式捕获 ScriptException 并通过 getLineNumber()、getMessage() 等方法定位语法错误；语法错误发生在解析阶段，区别于运行时异常；建议前置语法校验并根据 JDK 版本选择适配引擎。
在 Java 中用 ScriptEngine 执行动态脚本（如 JavaScript）时，语法错误会在 eval() 调用过程中直接抛出 javax.script.ScriptException，它本身已封装了语法异常信息，不需要额外捕获底层 JS 的 SyntaxError —— 因为 JS 引擎（如 Nashorn 或 GraalVM JS）在解析阶段就将语法问题转为该异常的子类型或附带详细提示。
明确捕获 ScriptException 并提取语法错误线索
ScriptException 是脚本执行失败的顶层异常，语法错误属于其典型触发场景。关键不是“怎么捕获”，而是“怎么识别并利用它”：
- 必须用
try-catch(ScriptException e)显式包裹eval()，不能只捕获Exception或忽略 - 调用
e.getFileName()、e.getLineNumber()、e.getColumnNumber()可定位错误位置（部分引擎支持，GraalVM 更稳定） - 调用
e.getMessage()通常含类似missing ; before statement或unexpected token的原始语法提示
避免把语法错误误判为运行时错误
语法错误发生在解析（parsing）阶段，早于执行；而 ReferenceError、TypeError 等是 JS 运行时异常，它们在 Java 层仍表现为 ScriptException，但堆栈和消息不同：
- 语法错误：消息里常含
parse、syntax、line X column Y，且e.getCause()通常是null或NullPointerException（旧 Nashorn 行为） - 运行时错误：消息可能含
ReferenceError、TypeError字样，e.getCause()可能是非空的 JS 异常包装对象（尤其在 GraalVM 中） - 不要依赖
instanceof判断 JS 错误类型——Java 层没有SyntaxError类，所有都统一为ScriptException
增强语法校验的实用做法
仅靠运行时报错被动捕获不够稳健，建议前置检查：
立即学习“Java免费学习笔记（深入）”；
- 对用户输入的脚本，先用轻量正则或 AST 工具（如 JSLint 的 Java 封装）做快速语法扫描，不依赖引擎
- 在开发/测试环境启用引擎的严格模式：例如传入
"use strict";\n" + script，让某些隐式错误提前暴露 - 若使用 GraalVM JS 引擎，可调用
Context.newBuilder().allowExperimentalOptions(true).option("js.ecmascript-version", "2022")提升语法兼容性与报错精度
注意 JDK 版本导致的差异
从 JDK 15 起 Nashorn 已移除，语法错误处理逻辑随引擎切换而变化：
- JDK 8–14（Nashorn）：语法错误报错较简略，
getLineNumber()偶尔不准 - JDK 15+（需自行引入 GraalVM JS）：语法错误提示更接近浏览器 DevTools，支持 Source Map 定位
- 务必检查
engine != null，否则eval()前就会抛NullPointerException，这不是语法问题，而是环境缺失
