{dump} ends the request right where it stands and answers with the debug dump of the engine: the message {dump} tag used, the stack, every level of the tag stack with its tag, type, parameters, content and flags, the application's variables, the stores, the request, the headers and the SQL and remote calls made so far. Nothing after the tag is processed - the output rendered so far is thrown away and the status is 500.

Who sees what depends on where the request comes from. A local request - the command line, or a loopback request with nothing forwarded - gets the full report inline - under the console output type the message, the template position and the directory the full report was written to. Any other visitor gets only the request id, or the application's _errors/500.pad when it has one, while the full report is written under DATA/dumps/, so a forgotten {dump} leaks nothing.

Use it to look at everything at one moment. To look at one value while the page goes on rendering, use {debug}; to follow the execution of a part of the page, {trace}. Like {exit} it never returns, so it has no content and no else branch.