• state_electrician
    link
    fedilink
    arrow-up
    2
    ·
    1 month ago

    The exception is part of the method signature and thus part of the return value. I don’t see a difference between using if or try-catch to validate a method call.

    • magic_lobster_party@kbin.run
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      I think try catch often leads to messy code. It breaks the control flow in weird ways. For some reason we’ve collectively agreed on that goto is a bad idea, but we’re still using exceptions for error handling.

      Consider this example:

      try {
          File file = openFile();
          String contents = file.read();
          file.close();
          return contents:
      } catch (IoException) {
      }
      

      Say an exception is triggered. Which of these lines triggered the exception? It’s hard to tell.

      We might want to handle each type of error differently. If we fail to open the file, we might want to use a backup file instead. If we fail to read the file, we might want to close it and retry with the same file again to see if it works better this time. If we fail to close the file, we might just want to raise a warning. We already got what we wanted.

      One way to handle this is to wrap each line around a separate try catch. This is incredibly messy and leads to problematic scopes. Another way is to have 3 different exception types: FileOpenException, FileReadException and FileCloseException. This is also incredibly messy.

      Or we can include the error in the return value. Then we can do whatever we want programmatically like any other code we write.

      • state_electrician
        link
        fedilink
        arrow-up
        1
        ·
        1 month ago

        How is that different than what Go, for example, does? An if err != nil after each statement is just as annoying. In the end you have to validate almost all return values and the way it happens is just syntax.