rt.deh - D Programming Language
Description: D Programming Language
Keywords: D programming language

Menu

- Learn
- Documentation
  - Language Reference
  - Library Reference
  - Command-line Reference
  - Feature Overview
  - Articles
- Downloads
- Packages
- Community
  - Blog
  - Orgs using D
  - Twitter
  - Forums
  - IRC
  - Community Discord
  - Wiki
  - GitHub
  - Issues
  - Get involved
  - Contributors
  - Foundation
  - Security Team
  - Donate
  - Sponsors
- Resources
  - Tour
  - Books
  - Tutorials
  - Tools
  - Editors
  - IDEs
  - run.dlang.io
  - Visual D
  - Acknowledgments
  - D Style
  - Glossary
  - Sitemap

Search
Report a bug
If you spot a problem with this page, click here to create a Bugzilla issue.
Improve this page
Quickly fork, edit online, and submit a pull request for this page. Requires a signed-in GitHub account. This works well for small changes. If you'd like to make larger changes you may want to consider using a local clone.

# rt.deh

Entry point for exception handling support routines.
There are three style of exception handling being supported by DMD: DWARF, Win32, and Win64. The Win64 code also supports POSIX. Support for those scheme is in rt.dwarfeh, rt.deh_win32, and rt.deh_win64_posix, respectively, and publicly imported here.
When an exception is thrown by the user, the compiler translates code like throw e; into either _d_throwdwarf (for DWARF exceptions) or _d_throwc (Win32 / Win64), with the Exception object as argument.
During those functions' handling, they eventually call _d_createTrace, which will store inside the Exception object the return of _d_traceContext, which is an object implementing Throwable.TraceInfo. _d_traceContext is a configurable hook, and by default will call core.runtime : defaultTraceHandler, which itself will call backtrace or something similar to store an array of stack frames (void* pointers) in the object it returns. Note that defaultTraceHandler returns a GC-allocated instance, hence a GC allocation can happen in the middle of throwing an Exception.
The Throwable.TraceInfo-implementing should not resolves function names, file and line number until its opApply function is called, avoiding the overhead of reading the debug infos until the user call toString. If the user only calls Throwable.message (or use Throwable.msg directly), only the overhead of backtrace will be paid, which is minimal enouh.
License:
Distributed under the Boost Software License 1.0. (See accompanying file LICENSE)
Authors:
Walter Bright

Source rt/deh.d

Copyright © 1999-2023 by the D Language Foundation | Page generated by Ddoc on Fri Jun 2 08:59:43 2023