If you can manage to ban the debugger, then you should rethink your entire debugging support strategy. A debugger infrastructure can be a core and critical com

If you can manage to ban the debugger, then you should rethink your entire debugging support strategy. A debugger infrastructure can be a core and critical component within a non-trivial application. This whether the integrated debugging is used for classic application debugging, for call tracing and basic performance monitoring, for creating and then processing application dumps on severe errors, for associated tasks including crash notifications and restarts and failure-related statistics collection, or otherwise. You build debugging in. From the onset. One OS environment that I work with can launch the system's debugger entirely under program control, which means the application can detect an "unexpected" failure and can (barring cases of severe corruptions) invoke application-specific debugger command sequences which can access and display the core application context, and a debugger-readable dump then be generated, and (if appropriate) the application then restarted. Logs never have enough data, and users (and programmers) don't always find and read logs. Better still, you don't have to switch techniques when you ship code; you're always using your primary tools. Bake debugging right into all non-trivial applications.