为什么前端开发者都不用 try finally 了？ - js - 前端 - 技术设计

在 JavaScript 开发过程中，资源管理一直是一个需要认真对待的问题。无论是文件句柄、数据库连接还是其他需要手动释放的资源，开发者都不得不编写繁琐的清理代码。传统的解决方案是使用 try…finally 结构，但这种方式往往导致代码冗长且易于出错。

# 资源管理的传统困境

在传统 JavaScript 编程中，处理需要显式释放的资源通常是这样的：

	let connection;
	try {
	connection = await database.connect(); // 使用连接执行操作
	const result = await connection.query("SELECT * FROM users");
	return result;
	} finally {
	// 确保连接关闭，即使发生错误
	if (connection) {
	await connection.close();
	}
	}

这种模式虽然有效，但存在几个明显的问题：

为了解决这些问题，TC39（负责 ECMAScript 标准的委员会）正在考虑引入 "using 声明"。这个提案受到了 C# 和 Python 等语言中类似特性的启发。

	using connection = await database.connect();// 使用连接执行操作
	const result = await connection.query("SELECT * FROM users");
	return result;// 代码块结束时自动关闭连接

当使用 using 声明时，JavaScript 会在变量离开作用域时自动调用其释放方法。这显著简化了资源管理逻辑。

using 声明依赖于一个名为 Symbol.dispose 的新符号。任何实现了这个符号方法的对象都被认为是 "可释放的"：

当 using 块的作用域结束时，引擎会自动调用对象的 Symbol.dispose 方法，确保资源被正确释放。

提案还包括对异步资源的支持，通过 await using 语法：

	awairt using connection = await database.connect();
	// 使用连接
	const result = await connection.query("SELECT * FROM users");
	// 自动等待异步关闭完成

在这种情况下，JavaScript 会等待 Symbol.asyncDispose 方法执行完成，然后再继续执行后续代码，确保异步资源被正确释放。

using 声明在很多场景下都能派上用场：

	async function readFile(path) {
	await using file = await fs.promises.open(path, 'r');
	return await file.readFile('utf8');
	}

	async function getUseerData(id) {
	await using connection = await db.connect();
	return await connection.query('SELECT * FROM users WHERE id = ?', [id]);
	}

	async function updateCounter() {
	await using lock = await mutex.acquire();
	const value = await storage.get('counter');
	await storage.set('counter', value + 1);
	}