new分配数组失败时抛出std::bad_alloc异常；c++标准规定默认行为是抛异常而非返回nullptr，与malloc本质不同，未捕获将导致程序崩溃。
new分配数组失败时抛出什么异常
C++标准规定，new（包括数组形式）在内存分配失败时默认抛出 std::bad_alloc 异常，不是返回nullptr。这和C风格的malloc完全不同，也和C++11后带nothrow的new行为不同。
- 默认
new int[1000000000]失败 → 抛std::bad_alloc - 使用
new (std::nothrow) int[N]失败 → 返回nullptr，不抛异常 - 如果全局
operator new被重载且没抛异常，行为由重载实现决定（但标准库默认实现一定抛）
所以，不捕获就直接崩溃——这是新手最容易忽略的一点：以为像指针判空一样处理，结果程序中途terminate。
如何安全捕获数组new的异常
用try/catch包围new表达式是最直接的方式。注意：异常发生在分配阶段，对象构造尚未开始，因此不需要担心析构问题。
try {
int* arr = new int[SIZE]; // 可能抛 std::bad_alloc
// ... 使用 arr
delete[] arr;
} catch (const std::bad_alloc& e) {
std::cerr
- 必须捕获
const std::bad_alloc&，而非值传递（避免拷贝） - 不要只捕获
std::exception&，因为bad_alloc是独立派生类，某些旧编译器可能匹配不精确 - 若在构造函数内做
new，异常会向外传播，需确保调用栈上有对应catch
为什么不用nothrow而坚持异常方式
std::nothrow看似“温和”，但隐藏了错误根源：
-
int* p = new (std::nothrow) int[LLONG_MAX];→p == nullptr，但你无法知道是OOM还是其他底层错误（如地址空间碎片） - 所有后续对
p的解引用都变成未定义行为，调试更困难 - 现代C++实践（如RAII、容器）默认依赖异常传播机制，混用
nothrow反而破坏一致性
除非你在嵌入式/实时系统中明确禁用异常（此时必须用nothrow并手动检查），否则应让new按标准行为抛异常，并集中处理。
vector替代方案是否真能避免这个问题
std::vector的resize或构造函数内部也是调用new，同样会抛std::bad_alloc。它只是帮你管理了delete[]，不改变异常语义。
try {
std::vector<int> v(SIZE); // 同样可能抛 bad_alloc
} catch (const std::bad_alloc&) {
// 处理逻辑一样
}</int>
-
vector::reserve()失败也会抛异常 - 但
vector提供了empty()、capacity()等接口，便于做预检（比如结合std::numeric_limits<size_t>::max() / sizeof(int)</size_t>估算上限） - 真正的优势是异常安全：即使构造元素时抛异常，
vector已分配的内存会自动释放
别指望vector“绕过”分配失败——它只是让错误处理更自然，而不是更隐蔽。关键还是得面对bad_alloc，而不是假装它不存在。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
