# Explicit exceptions - a solution to fragile code dealing with exceptions

**URL:** <https://es.discourse.group/t/explicit-exceptions-a-solution-to-fragile-code-dealing-with-exceptions/796>\
**Category:** 💡 Ideas\
**Created:** [May 18, 2021, 3:58pm UTC](https://es.discourse.group/t/explicit-exceptions-a-solution-to-fragile-code-dealing-with-exceptions/796 "2021-05-18T15:58:17Z")\
**Posts on this page:** 1\
**Page:** 4

<div class="post-metadata">

**Author:** ![claudiameadows](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/claudiameadows/32/126_2.png) [@claudiameadows](https://es.discourse.group/u/claudiameadows)\
**Post date:** [July 14, 2021, 2:53am UTC](https://es.discourse.group/t/explicit-exceptions-a-solution-to-fragile-code-dealing-with-exceptions/796/61 "2021-07-14T02:53:16Z")

</div>

Note: from an implementation perspective, there's little to realistically gain from `noexcept` or anything similar in JS, as JS doesn't have anything like C++'s destructors which have to be invoked even when exceptions propagate due to the absence of explicit `try`/`catch`.

_That is the real reason why C++ exceptions are largely avoided where pragmatically possible, and why a few languages (like Rust) deliberately split stack unwinding from standard error handling so they can just not call destructors during it (and avoid the gigantic performance cliff of having to set up a `try`/`finally` equivalent in almost every function that allocates things)._

[Previous page](https://es.discourse.group/t/explicit-exceptions-a-solution-to-fragile-code-dealing-with-exceptions/796.md?page=3)