The "exception that can only be inspected by single-stepping in a debugger" anti-pattern.

catch (Exception e)
Response.StatusCode = 500;
return Json("false");

Previous developer, I fucking hate you.

· · Web · 1 · 1 · 1

@progo at least he caught the exception. Usually ASP.NET Core will just set status 500 and send a canned response body otherwise

@coldacid The problem isn't so much hiding potentially secret details from the end user, it's the mouse gymnastics you have to go through to change it from the default.

@coldacid But in my sample at the start of this thread, the shit is preventing the Debugger from halting when the exception is first thrown.

The correct code would just let the UNHANDLED exception propagate to the end of the chain of command. In production mode it would give some unhelpful 500 error anyway; in debug mode it would halt the debugger when the exception is generated. Instead, my nemesis decided to catch and DROP the information about the exception.

@progo it'd be nice if it would halt the debugger in debug mode, but unless you've turned on break on exception throw, it won't because there's an exception handler up the stack that catches all exceptions to do that 500 result.

@coldacid exactly that's my complaint. The snippet at the top of this thread makes things worse. And it's an anti-pattern all over this project that I complained about before.

Sign in to participate in the conversation
No Agenda Social

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!