amorfo77/json
1
0
Fork 0
mirror of https://github.com/nlohmann/json.git synced 2026-07-11 21:15:10 +00:00
Code Issues Packages Projects Releases Wiki Activity

deploy: e9c3985f0a

Browse Source
This commit is contained in:
nlohmann
2026-07-10 14:08:26 +00:00
parent e86d443881
commit 7bc7ca0e06
301 changed files with 1230 additions and 510 deletions
Download Patch File Download Diff File Expand all files Collapse all files
home/debugging/index.html
+1
View File
File diff suppressed because one or more lines are too long
home/debugging/index.md
+17
View File
@@ -0,0 +1,17 @@
# Debugging
This page collects the library's built-in debugger integrations and other debugging-related features. They are not linked from a single place elsewhere in the docs, so are collected here.
## Visual Studio (natvis)
The repository ships [`nlohmann_json.natvis`](https://github.com/nlohmann/json/blob/develop/nlohmann_json.natvis) at its root, a [Natvis](https://learn.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects) file that gives `json`/`ordered_json` values a friendly, key/value debugger view instead of showing raw internal fields, when debugging with the MSVC debug engine (`cppvsdbg`) in Visual Studio or VS Code.
Debug engines that wrap LLDB instead of the MSVC debug engine (for example, `codelldb` in VS Code) only have partial/experimental Natvis support, and commonly fall back to showing raw internal fields even with the `.natvis` file present. Switching to `cppvsdbg` where available, or checking your debug extension's own Natvis support/version, are the next things to try if this happens. There is currently no bundled LLDB-native pretty-printer script in this repository.
## GDB
The repository ships a [GDB Python pretty printer](https://github.com/nlohmann/json/tree/develop/tools/gdb_pretty_printer) under `tools/gdb_pretty_printer`, with its own usage instructions in that directory's `README.md`.
## Extended exception diagnostics
Defining [`JSON_DIAGNOSTICS`](https://json.nlohmann.me/api/macros/json_diagnostics/index.md) before including the library augments `type_error`/`out_of_range`-style exceptions with a JSON Pointer to the offending value, which can help pinpoint where in a large document a runtime error occurred. This only applies to exceptions thrown *after* a value exists (e.g. during element access); parse errors, which happen before any value exists to point at, are not covered by this mechanism -- see [Parsing and exceptions](https://json.nlohmann.me/features/parsing/parse_exceptions/index.md) for how parse errors report their own location instead.