Hacker News Reader

Comment by city41 | Hacker News Reader

Several times throughout my career I've been hit with something erroring and it just being silent and completely stumping us. No error output, nothing. In a lot of these situations, we were able to track it down to some low level third party library doing `catch (e) {}`. The first one happened early in my career, and it was a good lesson. I don't take any error for granted, at the bare minimum I log it. You just never know, your software could still be used 5 years from now and in a totally different environment than you ever imagined.

View on HN

Oh this function is totally obvious to everyone on the team, no need to comment it.

30 years later:

/* X systems I modul body I 14.09.1990 */

void xxvcda(int *addr, int sizeof)

Ohhhhh yeah. I'm working on some code right now where the previous drive-by author trapped the underlying library's exceptions, then raised completely useless ones instead. He also didn't know how to use the language mechanism where you raise one exception "from" the previous one, to preserve context in the stack trace.

Fun stuff. At least this isn't for my job, which has its own fun.

This recently happened to me with DRF and JWTs -- the JWTs were invalid due to sporadic timing issues and we were unable to log in. There was no indication that anything was going on since DRF was swallowing the validation errors and returning a generic error, so I had to manually go down and add logging to find out what was even happening.

> DRF was swallowing the validation errors and returning a generic error

DRF assumes (for safety) that what you have is a public API. For JWT validation errors, you don't normally expect to have error-level logs, as it should be a problem of the API caller, not of the service.

However, if you are using DRF for an internal API, it is indeed useful to change the error handlers to, basically, add tracebacks to all the returned API errors.

Reply on news.ycombinator.com