6 ms·

How is using Sentry (or whatever) not adding complexity? How is Sentry not introducing side effects? How is using Sentry magically creating information about wh

by fuzzy2 5y ago

How is using Sentry (or whatever) not adding complexity? How is Sentry not introducing side effects? How is using Sentry magically creating information about why a business operation failed? Does Sentry even know your business operation failed? It doesn’t, unless you tell it. How is Sentry not I/O-bound? (That’s right, they abstracted that away, like a good logging framework does, too.) In the end, to integrate Sentry and get actually useful information for monitoring, you have to do the same work you’d do for logging. Except now you’re tied to Sentry. Want some other service? Good luck. Do log. And then send the log messages to Sentry or whatever you’re using, too. Also, do overlog. It can be hard or impossible to attach a debugger to the deployed application. But you can always turn the log level up to 11 and then reconstruct what happened from the log messages.

konschubert 5y ago
I think what the post is trying to say is that you should let your exception bubble up. And then catch it at the highest level, including all the stack trace. And then maybe send it to sentry, or log it, put it on data dog. But don't catch exceptions all over your application code. I have a related mental model for this: When you crash, crash loudly.
- masklinn 5y ago
  That, however, does not at all work when exceptions are part of the "normal" process and should be ignored or cleanly retried (having spent a while interacting with github, if you take the entire thing down every time github replies with an error and log that to sentry, your sentry instance will last all of 5mn before you have to declare bankruptcy or just plonk the alters and ignore everything). But in that case you probably still want to know about these failures, so you can review them from time to time, or see if there are upticks in failure frequency.
  - Veuxdo 5y ago
    Exceptions should not be normal by definition.
    - deleted 5y ago
      [deleted]
    - contravariant 5y ago
      With some systems I have indeed been tempted a few times to only throw an exception if everything went right in one try, but my suggestions have been rejected so far.
    - mkohlmyr 5y ago
      That's a wonderful theory. I have a third party which returns errors ~20% of the time outside of working hours (yes, really). 1. Exceptions should be sent to sentry. 2. Exceptions should not be normal. 3. Do not log. Solve for ability to review & debug after the fact.
      - Veuxdo 5y ago
        If it doesn't work that often, then it isn't an expectation. That's just how it works.
      - frenchyatwork 5y ago
        > I have a third party which returns errors ~20% of the time outside of working hours Then presumably those errors shouldn't be exceptions. Of course, there's a lot of a lot of assumptions behind this: 1. You have control over the code that interfaces with the third party. Otherwise presumably you'd have to write a shim that catches the exception and turns it into an error value, and that's probably not worth the effort. 2. You're work in a language that doesn't type check exceptions (i.e. not Java with checked exceptions) and your language also doesn't have a nicer way of handling errors as a (discriminated) union. 3. Your co-workers will go complete bananas if you start using some sort of result type or [success, value|error] tuple instead of an exception because that's how they've done it for 20 years. The reason for this is that exceptions in most languages escape the type system and are in general more awkward to catch. Of course, I'd also disagree with "do not log" in this context, though I might prefer a logging mechanism that allowed me to write queries on it (like recording values in a database).
  - konschubert 5y ago
    That, or a count metric.
  - chousuke 5y ago
    I think errors and failures get often conflated. There are truly exceptional situations where your application can do nothing and will just have to abort (passing off the failure to a higher layer in the system) but often failures aren't really exceptional. You can not assume that your database connections live forever, for example, and it's not an error when a commit fails due to an interrupted network connection. Such cases need to be handled. If you know that an operation is unreliable, you need to add retry / recovery logic and perhaps log or increment a metric that you can track what's going on; a high number of failures often indicates an exceptional situation. In some cases, your retry logic will be a "Please try again" message to the user. I think that's perfectly acceptable, but you'll still want to know about it.
- fuzzy2 5y ago
  Not really a point I read in TFA but I agree. Catching just to log something is generally wrong.
  - simion314 5y ago
    > Catching just to log something is generally wrong Yes, but you should catch as soon as possible (or validate stuff as soon ass possible) and re-throw with a better error message if possible. You will thank yourself when some problem appears and instead of a random "errorcode 123" you get a detailed message like "Operation Xyz failed with errorcode 123";
- vanusa 5y ago
  I think what the post is trying to say is that you should let your exception bubble up. Usually, but not always. That is, for the classic "exceptions should only be used in exceptional cases" scenario, this is usually what you want to do. A good portion of the time, though, this scenario doesn't apply. You're dealing with a subsystem that is throwing an exception (for good reasons or bad) but no, you don't want to just the application crash. You want to ... catch it, and do something else. Which is what try-catch was devised for in the first place, after all.
- KallDrexx 5y ago
  > I think what the post is trying to say is that you should let your exception bubble up. It's not an either-or situation though. Even if you let the exception bubble up and sentry logs the exception, logging performed prior to the exception and at the time the exception is caught (prior to being bubbled up) as valuable context to how the exception happens, which can lower debugging time. The exception just tells you that something went done, it doesn't always have the reason why something went wrong. And the context for why is not always available at the time of raising the exception (the context may be from a prior function call, or the consumer of the function that raised the exception).
- ninkendo 5y ago
  Eh... a lot of this article can be reworded as "do error handling better" (make error paths unreachable through your type system, crash for unrecoverable errors, if errors are recoverable, they should be Results, etc etc.) Ok, I did all that. And I still want to know why this bug report happened, and logs help me. Why should I Not Log?
kemitche 5y ago
Also... Sentry is logging. It's a very fancy logger that can capture all sorts of data about the exception and what was happening - but at its core, it's still a essentially a logger.
- wldcordeiro 5y ago
  I was thinking the same thing once they got to that point! Our "logger" is literally a library from DataDog, but Sentry has similar (we actually migrate from Sentry to DataDog at my job) and there's tons of other services now that do similar with "loggers" as well. There is good advice here about questioning when to log but Sentry and its peers are loggers.
- fourseventy 5y ago
  Ya exactly. I came here to say this too.
jaredsohn 5y ago
>Except now you’re tied to Sentry. Want some other service? Good luck. If this is a concern, just create a class with a method that takes an exception, message, context, etc. as parameters and use that. Now you can change it in one place instead of throughout your codebase. Agree on logging messages as well; is useful to see live what is happening in the system as well as it is useful to see logging broken up by different errors
outworlder 5y ago
> Also, do overlog. It can be hard or impossible to attach a debugger to the deployed application. But you can always turn the log level up to 11 and then reconstruct what happened from the log messages. Please don't overlog. Only ever do this if you can dynamically change your log level on demand, without impacting users. If you do have to reconstruct a sequence of events and you do not have distributed tracing, fine. Log the sequence of events _when needed_. But please don't log messages on a perfectly fine system for no reason. It's noise and health can be better served by looking at metrics. Because of this overlogging nonsense our systems generate terabytes of logs daily. Most of it is never ever looked at.
- fuzzy2 5y ago
  Well yes of course? That’s what log levels and log categories are for. Whether the configuration can change at runtime or if your services have to cycle doesn’t really matter IMHO.

by fuzzy2 5y ago

konschubert 5y ago

I think what the post is trying to say is that you should let your exception bubble up. And then catch it at the highest level, including all the stack trace. And then maybe send it to sentry, or log it, put it on data dog. But don't catch exceptions all over your application code. I have a related mental model for this: When you crash, crash loudly.

masklinn 5y ago
That, however, does not at all work when exceptions are part of the "normal" process and should be ignored or cleanly retried (having spent a while interacting with github, if you take the entire thing down every time github replies with an error and log that to sentry, your sentry instance will last all of 5mn before you have to declare bankruptcy or just plonk the alters and ignore everything). But in that case you probably still want to know about these failures, so you can review them from time to time, or see if there are upticks in failure frequency.
- Veuxdo 5y ago
  Exceptions should not be normal by definition.
  - deleted 5y ago
    [deleted]
  - contravariant 5y ago
    With some systems I have indeed been tempted a few times to only throw an exception if everything went right in one try, but my suggestions have been rejected so far.
  - mkohlmyr 5y ago
    That's a wonderful theory. I have a third party which returns errors ~20% of the time outside of working hours (yes, really). 1. Exceptions should be sent to sentry. 2. Exceptions should not be normal. 3. Do not log. Solve for ability to review & debug after the fact.
    - Veuxdo 5y ago
      If it doesn't work that often, then it isn't an expectation. That's just how it works.
    - frenchyatwork 5y ago
      > I have a third party which returns errors ~20% of the time outside of working hours Then presumably those errors shouldn't be exceptions. Of course, there's a lot of a lot of assumptions behind this: 1. You have control over the code that interfaces with the third party. Otherwise presumably you'd have to write a shim that catches the exception and turns it into an error value, and that's probably not worth the effort. 2. You're work in a language that doesn't type check exceptions (i.e. not Java with checked exceptions) and your language also doesn't have a nicer way of handling errors as a (discriminated) union. 3. Your co-workers will go complete bananas if you start using some sort of result type or [success, value|error] tuple instead of an exception because that's how they've done it for 20 years. The reason for this is that exceptions in most languages escape the type system and are in general more awkward to catch. Of course, I'd also disagree with "do not log" in this context, though I might prefer a logging mechanism that allowed me to write queries on it (like recording values in a database).
- konschubert 5y ago
  That, or a count metric.
- chousuke 5y ago
  I think errors and failures get often conflated. There are truly exceptional situations where your application can do nothing and will just have to abort (passing off the failure to a higher layer in the system) but often failures aren't really exceptional. You can not assume that your database connections live forever, for example, and it's not an error when a commit fails due to an interrupted network connection. Such cases need to be handled. If you know that an operation is unreliable, you need to add retry / recovery logic and perhaps log or increment a metric that you can track what's going on; a high number of failures often indicates an exceptional situation. In some cases, your retry logic will be a "Please try again" message to the user. I think that's perfectly acceptable, but you'll still want to know about it.
fuzzy2 5y ago
Not really a point I read in TFA but I agree. Catching just to log something is generally wrong.
- simion314 5y ago
  > Catching just to log something is generally wrong Yes, but you should catch as soon as possible (or validate stuff as soon ass possible) and re-throw with a better error message if possible. You will thank yourself when some problem appears and instead of a random "errorcode 123" you get a detailed message like "Operation Xyz failed with errorcode 123";
vanusa 5y ago
I think what the post is trying to say is that you should let your exception bubble up. Usually, but not always. That is, for the classic "exceptions should only be used in exceptional cases" scenario, this is usually what you want to do. A good portion of the time, though, this scenario doesn't apply. You're dealing with a subsystem that is throwing an exception (for good reasons or bad) but no, you don't want to just the application crash. You want to ... catch it, and do something else. Which is what try-catch was devised for in the first place, after all.
KallDrexx 5y ago
> I think what the post is trying to say is that you should let your exception bubble up. It's not an either-or situation though. Even if you let the exception bubble up and sentry logs the exception, logging performed prior to the exception and at the time the exception is caught (prior to being bubbled up) as valuable context to how the exception happens, which can lower debugging time. The exception just tells you that something went done, it doesn't always have the reason why something went wrong. And the context for why is not always available at the time of raising the exception (the context may be from a prior function call, or the consumer of the function that raised the exception).
ninkendo 5y ago
Eh... a lot of this article can be reworded as "do error handling better" (make error paths unreachable through your type system, crash for unrecoverable errors, if errors are recoverable, they should be Results, etc etc.) Ok, I did all that. And I still want to know why this bug report happened, and logs help me. Why should I Not Log?

kemitche 5y ago

Also... Sentry is logging. It's a very fancy logger that can capture all sorts of data about the exception and what was happening - but at its core, it's still a essentially a logger.

wldcordeiro 5y ago
I was thinking the same thing once they got to that point! Our "logger" is literally a library from DataDog, but Sentry has similar (we actually migrate from Sentry to DataDog at my job) and there's tons of other services now that do similar with "loggers" as well. There is good advice here about questioning when to log but Sentry and its peers are loggers.
fourseventy 5y ago
Ya exactly. I came here to say this too.

jaredsohn 5y ago

>Except now you’re tied to Sentry. Want some other service? Good luck. If this is a concern, just create a class with a method that takes an exception, message, context, etc. as parameters and use that. Now you can change it in one place instead of throughout your codebase. Agree on logging messages as well; is useful to see live what is happening in the system as well as it is useful to see logging broken up by different errors

outworlder 5y ago

> Also, do overlog. It can be hard or impossible to attach a debugger to the deployed application. But you can always turn the log level up to 11 and then reconstruct what happened from the log messages. Please don't overlog. Only ever do this if you can dynamically change your log level on demand, without impacting users. If you do have to reconstruct a sequence of events and you do not have distributed tracing, fine. Log the sequence of events _when needed_. But please don't log messages on a perfectly fine system for no reason. It's noise and health can be better served by looking at metrics. Because of this overlogging nonsense our systems generate terabytes of logs daily. Most of it is never ever looked at.

fuzzy2 5y ago
Well yes of course? That’s what log levels and log categories are for. Whether the configuration can change at runtime or if your services have to cycle doesn’t really matter IMHO.