先说几个核心判断：在 Atom 编辑器里折腾代码运行报错，很多人一开始就容易走偏——总觉得“编辑器应该能自己抓到异常”。但实际根本不是这么回事。
Atom 本身不捕获、也不处理代码运行时异常。它不是运行环境，没有 try/catch、没有 error 监听器，更不会介入解释器进程的错误流。所有你在界面上看到的“运行报错”，本质上都是外部命令（比如 python 或 node）执行失败后，由插件（典型的就是 script）把终端里的输出原样搬到了编辑器面板上。所以，想“测试代码运行报错”，关键不在 Atom 设置里翻来覆去地调，而在于如何让错误真正被触发、并且能被你看见。
script 插件执行时看不到报错信息？检查 stdout/stderr 是否被吞掉
实际操作中你会遇到一个很常见的尴尬场景：在 Python 文件里故意写了个 1/0，满怀期待地运行 script 插件，结果屏幕上干干净净，啥反应没有，甚至直接卡住。这时候第一反应不应该是怀疑代码，而要反思一下：错误信息是不是被插件吞了？
script插件默认会带-u（unbuffered）参数运行 Python，但在某些 Windows 环境或旧版 Python 下，stderr 仍然可能被缓冲，导致错误信息迟迟刷不出来。- 如果插件配置里把
command写成了pythonw.exe（Windows 的 GUI 版解释器），好家伙，它会把所有 stderr 输出静默丢弃，你当然看不到任何报错。 - 还有一部分情况是 Atom 内置终端组件的限制——旧版本尤其容易出问题，对 ANSI 控制字符或者长堆栈跟踪会直接截断。
实操建议倒是很直接：打开 atom://config，找到 script 包的设置，把 command 明确写成 python.exe（Windows）或 python3（macOS/Linux），同时确认没勾选“Hide output when successful”。如果还不放心，可以临时加一句 print("DEBUG: start")，先确认流程确实走通了。
报错显示 createfile : the system cannot find the file specified？路径解析失败
这可能是 Windows 上最经典的 script 插件报错。注意，这个错误本身跟你的代码一点关系都没有——是插件压根找不到解释器或者脚本路径。
- 错误里的
createfile来源于底层 Node.js 的spawn调用失败，说明 script 尝试去执行一个根本不存在的命令。比如你配置里写了个py，但系统 PATH 里根本没配好。 - 如果脚本路径里带了中文、空格或 Unicode 字符，旧版本的 script 插件（尤其那些没做好 shell-escape 的）经常因为没加引号而解析失败。
- 更底层的原因是：
filepath参数传入时没做path.normalize()或shell-escape，在跨平台场景下非常容易出事。
实操建议：在 script 配置的 args 字段里，显式把路径包起来：写成 ['-u', '"'+filepath+'"']。同时，为了彻底避免 PATH 查找的问题，command 最好直接写成绝对路径，比如 C:\Python39\python.exe。
想让 Atom 自动捕获 JS/Python 运行时异常？得靠语言服务，不是编辑器
Atom 没有内置运行时沙箱，也没有办法 hook 解释器的异常抛出机制。所谓“捕获异常”，其实只能走两条路：
- 前端 JS 方面，靠
linter-jshint或linter-eslint做静态分析，在保存文件时提示潜在问题（比如ReferenceError）。但要搞清楚，这是编译期检查，跟运行时是两个世界。 - Python 或 Node 的调试，必须借助
hydrogen（基于 Jupyter kernel）或atom-debugger（对接 VS Code Debug Adapter Protocol），它们通过标准调试协议接收断点命中和异常事件。 - 至于直接运行（非调试模式）的脚本，异常只能靠终端输出的文本形式去识别。你可以自己写个简单的正则去匹配
Traceback或Uncaught关键字，但 Atom 本身不提供任何原生支持。
这里需要提一嘴：exception-reporting 这个包只捕获 Atom 自身的 Electron 主进程/渲染进程异常（比如某个插件 JS 报错了），它跟你运行的 Python 或 Node 子进程完全无关。别指望它能帮你抓到业务代码里的 bug。
调试时断点不触发、异常不中断？检查 hydrogen 的 kernel 连接状态
不少人装了 hydrogen 就以为能直接开始调试了，结果发现断点根本不触发。问题大概率出在 kernel 的连接状态上。
- 打开一个
.py文件后，看一下右下角状态栏。如果显示的是Hydrogen: Python 3.x.x，说明一切正常；如果显示Not connected，那 kernel 启动就失败了。 - 常见原因：没有全局安装
ipykernel（需要python -m pip install ipykernel），或者python-language-server没跑起来，导致氢无法获取 AST 结构。 - 另外，异常中断需要手动开启 Debug 模式（Ctrl+Shift+P → “Hydrogen: Toggle Debug Mode”）。否则就算抛出
Exception，它也只打印堆栈，不会帮你暂停执行。
一个很实用的验证方式：在代码开头加一句 import sys; sys.breakpointhook = lambda *a: __import__('pdb').set_trace()，强制进 pdb。如果能停下来，说明是 hydrogen 的配置问题；如果连 pdb 都不进，那就是解释器根本没执行到那一行——路径、编码或语法错误在更早的阶段就把进程拦住了。
说到底，真正难的不是看到报错，而是分清这三类信号：插件配置错误（比如 createfile）、解释器自身的异常（比如 ZeroDivisionError）、以及 Atom 自身的崩溃（exception-reporting 弹窗）。它们全都显示在同一个终端输出里，但修复路径完全不同。搞清楚这个，你才算真正掌握了在 Atom 里“测试代码运行报错”的门道。
