When do you apply error catching and when not?

When do you apply error catching and when not? Accessing something external seems an obvious occasion, but even multiplying two ints could cause a trip in theory.

Beware Cat Shirt $21.68

Rise, Grind, Banana Find Shirt $21.68

Beware Cat Shirt $21.68

  1. 3 weeks ago
    Anonymous

    encase every statement in its own try catch block

  2. 3 weeks ago
    Anonymous

    whenever I actually have a plan b in case of errors. like, in most cases if malloc fails because it ran out of memory, the program should just panic, there isn't much else to do

  3. 2 weeks ago
    Anonymous

    if it's logical to handle an exception at the level you're looking at, catch and handle. otherwise, throw

  4. 2 weeks ago
    Anonymous

    >When do you apply error catching
    never
    >and when not?
    always
    >Accessing something external seems an obvious occasion
    no, just return error from a function and handle it like any other return value
    >but even multiplying two ints could cause a trip in theory.
    bruh

    • 2 weeks ago
      Anonymous

      I like the idea of Go but I just use Python instead.

      • 2 weeks ago
        Anonymous

        >I like the idea of women, but I frick trannies instead
        weird flex but ok

        • 2 weeks ago
          Anonymous

          >python is the troony

          • 2 weeks ago
            Anonymous

            it's literally called "python", as in, the "python" between her legs

  5. 2 weeks ago
    Anonymous

    >When do you apply error catching and when not?
    Use try-catch when you are going to do something with the caught exception, even if it is just log and re-throw.

    Calling external API over internet failed? Catch exception and try again.

    Adding two numbers failed? You probably can't do anything about that, let the higher layers to handle the resulting exception.

  6. 2 weeks ago
    Anonymous

    A lone try catch in the repeating process that has to do 1 million things, I don't care why it fails, and it is not recoverable.
    Everything else, you can handle.

  7. 2 weeks ago
    Anonymous

    Generally you should never apply error catching if you can help it because it runs the risk of you swallowing critical errors and making things worse than they would have been.

    The few cases where it makes sense to apply error catching include orchestration programs where you want to retry or dead letter bad requests from worker functions without blowing up the whole orchestrator. Basically having the try catch in your main function. Though an argument could be made that your orchestrator and workers should be different programs which interface with each other anyway.

    • 2 weeks ago
      Anonymous

      >it runs the risk of you swallowing critical errors and making things worse than they would have been.
      Could you give an example?
      Couldn't that be avoided by catching only particular types of errors?

      • 2 weeks ago
        Anonymous

        >Could you give an example?
        You swallow a division by zero error and propagate NaN throughout your business logic. You operate a financial firm and undoing commits requires more than rolling back a production change because real contracts have been signed and real money exchanges hands.
        >Couldn't that be avoided by catching only particular types of errors?
        Yes, which is exactly what you should do if you do need to perform some kind of error handling. Fine tune for known errors and handle as appropriate, let any others that you did not account for bubble up.

  8. 2 weeks ago
    Anonymous

    Is there difference between an Error and Exception?

    • 2 weeks ago
      Anonymous

      as far as Java goes: Exceptions you're expected to catch somewhere in your application while Errors you should not
      both are subclasses of Throwable
      https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Throwable.html

    • 2 weeks ago
      Anonymous

      Error is a type synonym for Either and Exception is a type class whose instances can be caught and thrown in the IO monad.

  9. 2 weeks ago
    Anonymous

    exceptions are a moronic idea for error handling. you either ignore a huge amounts of possible exceptions (any single line of code with a "new" in it can throw an OutOfMemoryException at any time just because someone else's program had a memory leak 🙂 how many people do you see try-catching every single new for outofmemory? ) or you just put the entire program into a gigantic try-catch which is also moronic. rust's result type is the best way to handle errors i've seen by far

  10. 2 weeks ago
    Anonymous

    i immediately know that a pajeet wrote code when i see try/exception code

  11. 2 weeks ago
    Anonymous

    Mostly system boundaries. You need a pretty big reason to have exception handling the core of your application. There are no excuses to have that in your domain.

Your email address will not be published. Required fields are marked *