![]() ![]() They'll see a crash and add try…catch around it so that it doesn't complain. I've noticed a habit of early software engineers that they tend to fix the error, not the bug. If you don't also call the catch method, you probably have a silent failure in your application.īrief rant: silent failure is the worst kind of failure. For example, let's say that your code relies on some Promise value, and you aren't using await syntax, but using the "then" method. There are ways to write code that gives good tracebacks and ways to screw it up. Logs are an unstructured mess, but if you spend some time searching through them, they can often answer hard questions about out-of-memory errors and the like. But there are important details that are captured only by logs - errors from system-level software, logs of deployments, debugging information, timing data. Logging & error tracking can really be two sides of the same coin - some errors produce logs, and some logs are captured by Sentry as the context to errors. ![]() Render has rudimentary logging built in, but I recently added Logtail for longer-retention logs that I can search through. Then, you can look at them all on a dashboard and try and fix everything on that list, one by one. Sentry aims to hook into all of the ways your application can crash or produce an error, and send all of those errors to its service. If you only had one system, I think it'd be error tracking. I use Sentry, because I have a lot of experience using it at Mapbox and Observable, and they have an actively-maintained integration for Next.js, which works okay with Blitz. Interpreting bugs shouldn't be an art, but it is.īut to even have a fighting chance to achieve these goals, you need a few systems.įirst, error tracking. The issues with Sentry produced a bug report that didn't point to any particular system or line of code. For example, the issues with Blitz I encountered only manifested in production. We don't live in a perfect world, and usually none of these things are absolutely true. And when you have a fix, you can deploy it immediately and confirm that the bug is gone. Every bug that happens in production can be reproduced locally. In a perfect world, every bug would have a detailed and accurate report that let you track down its origin. What matters is your ability to notice, diagnose, and fix those bugs: to create a feedback loop. You can reduce the number of bugs, but you can never really get to zero. It doesn't matter if you have a fancy type system or robust unit tests. Fixing broken softwareĪll software has bugs. It's a lot of work, but it's a lot easier for you to isolate and diagnose a bug you're seeing than it is for someone without access to your setup. Being willing to do that, to spend a day hunting down a bug that you didn't write, seems essential.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |