• kbal
      link
      fedilink
      49
      edit-2
      9 months ago

      Super-advanced java devs like me do it like try{} catch (Exception e) { System.out.println("something went wrong"); e.printStackTrace(); }

          • @tool
            link
            English
            89 months ago

            On Error Resume Next never before have more terrible words been spoken.

            Every time I’m reading a PowerShell script at work and see -ErrorAction SilentlyContinue I want to scream into a pillow and forcefully revert their commit.

            I’ve actually done it a few times, but I want to do it every time.

        • @kaffiene
          link
          English
          49 months ago

          Yeah cos everyone knows other languages are impossible to write bad code with

    • @[email protected]
      link
      fedilink
      79 months ago

      you can follow any exception down to the exact line of code

      Which is usually not a piece of code written by us and is caused by another piece of code not written by us either

      • @[email protected]
        link
        fedilink
        10
        edit-2
        9 months ago

        Does your IDE not highlight the lines written by you in a different colour? Of course that doesn’t help when it’s an error in production!

          • @[email protected]
            link
            fedilink
            39 months ago

            I thought it highlighted the line number in blue when it was your code. I use eclipse so can’t properly remember

    • @[email protected]
      link
      fedilink
      49 months ago

      but you can follow any exception down to the exact line of code (or JNI call, I guess) where the problem occurs.

      But, it’s not really where the problem occurred. How often do you get a stack trace and the bug fix is at the line referenced by the stack trace? Almost never. It’s more that it takes you down to the exact line of code where the effects of the problem are bad enough to affect the running of the program. But, the actual problem happened earlier, sometimes much earlier.

      For example, NullPointerException isn’t actually the problem, it’s a symptom of the problem. Something didn’t get initialized properly, and nobody noticed for a while, until we tried to use it, and got a null pointer. Sometimes it’s easy to go from the effect (null pointer) to the cause (uninitialized thing). But, other times that “thing” was passed in, so you have to work backwards to try to figure out where that thing comes from, and why it’s in that broken state.

      Sure, it’s better than nothing, but it’s still frustrating.