• hummas@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      4
      ·
      10 months ago

      I’m even more disturbed by the try catch that will never catch anyway. Most disturbing is the absolute heresy that is the throw within the catch. …is vibe even defined here??? I think I need to reconsider my major.

        • hummas@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          1
          ·
          10 months ago

          Kind of a knee-jerk reaction to it on my part, plus I’ve got personal bias against exceptions (errors as values my beloved). The worst thing is that thinking about this code has managed to take time I could’ve used being non-productive with my own projects smh.

          • nyjan@feddit.de
            link
            fedilink
            arrow-up
            2
            ·
            10 months ago

            My personal take on this, at least when dealing with more complex or production code:

            Performance is not an issue with exceptions if you don’t use them for control flow, they should be an unusual occurrence wherever possible.

            If you expect to throw and later handle an exception regularly, I’d try to include relevant info about the failure in the returned value, or even better in the returned type, and skip throwing the exception altogether.

            Returning a type that contains both error info and the actual result (if there is one) and forces the caller of your function to handle any contained error info before being able to access the actual result has the same effect as a try/catch block without the major performance implications.

            This is basically what rust does everywhere in order to completely remove the concept of exceptions, but it’s a nice performance optimization for langues with exceptions as well.

            Exceptions should interrupt your programs flow, not control it, at least in all hot execution paths. Thanks for coming to my ted talk