Summary

Five methods in DebugStorage silently swallowed JSON parse and object construction errors with empty catch blocks. If stored debug data gets corrupted, users lose all their breakpoints, function breakpoints, exception breakpoints, data breakpoints, and watch expressions — with zero indication of failure.

Problem

In src/vs/workbench/contrib/debug/common/debugStorage.ts, these five methods had empty catch (e) { } blocks:

Corruption scenario: If IndexedDB/localStorage data becomes corrupted due to sync conflicts, disk errors, crash mid-write, or a serialization bug, JSON.parse() throws — the empty catch drops the exception, the method returns [], and the user is left wondering why all their carefully-set breakpoints just disappeared.

Fix

Replace each empty catch (e) { } with this.logService.error('message', e). The class already has ILogService injected in its constructor but was not using it in these catch blocks.

- } catch (e) { }
+ } catch (e) {
+     this.logService.error('Failed to load breakpoints from storage', e);
+ }

Why this is the right fix

1. Surfaces corruption — Errors are logged to the developer console and log service, enabling diagnosis
2. No behavior change — Still returns empty arrays on parse failure (graceful degradation)
3. Minimal and low-risk — logService is already injected via DI, no new dependencies
4. Follows existing patterns — The loadBreakpoints method already passes this.logService to new Breakpoint(), so the infrastructure is already wired

Testing

• Existing behavior preserved — errors still caught, empty arrays returned
• Log output appears in developer console when data is corrupted
• No functional change to debug workflows

Closes #319805

Co-authored-by: Muhammad Ishaq Khan muhammadishaqkhan.2321@gmail.com