# Swift Testing: still no way to disable \_swift\_setWillThrowHandler? **URL:** \ **Category:** Swift Testing\ **Created:** [April 3, 2026, 6:23pm UTC](https://forums.swift.org/t/swift-testing-still-no-way-to-disable-swift-setwillthrowhandler/85805 "2026-04-03T18:23:22Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [April 3, 2026, 6:23pm UTC](https://forums.swift.org/t/swift-testing-still-no-way-to-disable-swift-setwillthrowhandler/85805/1 "2026-04-03T18:23:22Z")
a long time ago, when Swift Testing first came out, it was discovered that many types of parsers could not run within a Swift Testing suite, because Swift Testing attached some runtime hook to Swift’s error propagation (`_swift_setWillThrowHandler`), and this resulted in an unacceptable slowdown in parser performance, due to the parser using Swift errors internally for its control flow. this is virtually unnoticeable in normal production builds, as it gets optimized out, but in a Swift Testing test suite, parsing slows to a crawl, as errors will be thrown and caught inside the parser on virtually every UTF-8 byte. this can cause parsing to become hundreds of times slower. in some unit tests, this is tolerable, because payloads are small enough that even a 200x regression in parser performance still completes in a reasonable amount of time. but for more complex tests that involve loading some real-world data (like a 5 MB JSON file), this is a total blocker preventing Swift Testing adoption. in Swift 6.3, is still no way to safely disable `_swift_setWillThrowHandler` for a single test suite? ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [April 3, 2026, 6:26pm UTC](https://forums.swift.org/t/swift-testing-still-no-way-to-disable-swift-setwillthrowhandler/85805/2 "2026-04-03T18:26:53Z")
You can set the environment variable `"SWT_SWIFT_ERROR_BACKTRACING_ENABLED"` to `"0"` to disable this functionality in your process. There is no high-level per-test interface for it though as the hook function is global state. ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [April 3, 2026, 6:30pm UTC](https://forums.swift.org/t/swift-testing-still-no-way-to-disable-swift-setwillthrowhandler/85805/3 "2026-04-03T18:30:25Z")
> [@grynspan](#): > > SWT\_SWIFT\_ERROR\_BACKTRACING\_ENABLED that’s perfect, it’s exactly what i needed. i vaguely remembered something like this existing from a long-lost Slack conversation, but couldn’t find any trace of it anywhere even after prodding a few LLMs. thank you so much! ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [April 3, 2026, 7:20pm UTC](https://forums.swift.org/t/swift-testing-still-no-way-to-disable-swift-setwillthrowhandler/85805/4 "2026-04-03T19:20:19Z")
I was going to look up that Slack convo and link to it here, but was worried it would read as passive-aggressive. Note that our environment variable use is not considered stable API surface! Especially those starting with "SWT", which we will someday migrate to "SWIFT\_TESTING". ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [April 3, 2026, 8:07pm UTC](https://forums.swift.org/t/swift-testing-still-no-way-to-disable-swift-setwillthrowhandler/85805/5 "2026-04-03T20:07:04Z")
yes… this is part of why i despise Slack… so much information i vaguely recollect, that does not exist anywhere else, lost forever because of Salesforce’s 90-day access horizon…