• eletes@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    0
    ·
    7 months ago

    Holy fuck whoever was in charge of setting up that disaster recovery needs a million dollar bonus. I get that they’re managing $80B and this should all be standard but people usually don’t listen to IT and take DR seriously. And even if you do set it up, are you going back to check that your backups are functioning properly and have alarms for when it messes up

  • Carighan Maconar@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    7 months ago

    I mean I was originally angry about this toss-up, but since it hit an investment company… good guy Google?

    I’m confused now.

    • 520@kbin.social
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      This company wasn’t exactly targeted. It could have happened to literally anyone.

    • galoisghost@aussie.zone
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      UniSuper is a superannuation fund (think 401k), it’s one of the good ones in that it doesn’t take commissions and profits go to members

      Stay confounded at Google’s incompetence.

    • Eager Eagle@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      6 months ago

      nothing wrong with that - it is an exception, as in, the customer is likely lost after that anyway.

    • snekmuffin@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      Tbf python guidelines encourage it over if/else in cases like this. “Easier to ask for forgiveness than for permission” or something along the lines

      • bjornsno@lemm.ee
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        Day 598 of asking for a way to tell which functions throw exceptions in Python so I can know when to wrap in try catch. Seems to me that every other language has this, but when I’ve asked for at least a linter that can tell me I’m calling a function that throws, the general answer has been “why would you want that?”

        How am I supposed to ask for forgiveness if it’s impossible to know that I’m doing something risky in the first place?

          • bjornsno@lemm.ee
            link
            fedilink
            arrow-up
            0
            ·
            6 months ago

            Respectfully, no. Rust is great for some things and Python is great for other things. Switching to rust is not a solution to missing exception linting in another language.

        • ScreaminOctopus@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          0
          ·
          7 months ago

          Yeah, for this reason I would pretty much never encourage exceptions in Python over some other form of error handling. It’s so frustrating when called code throws some random exceptions that are completely undocumented. This is one of the few things Java got (sort of) right

          • bjornsno@lemm.ee
            link
            fedilink
            arrow-up
            0
            ·
            6 months ago

            Well at least php has it, which is a JITed scripting language just like Python. Although saying php has it is wrong, it’s just a special doc tag that the linters pick up. Which is exactly what I want for Python. The only other scripting language I’m very comfortable with is typescript, which can also support @throws via jsdoc and eslint.

            So to answer your question, I don’t know if it’s common, but from my minimal sample pool it’s at least not unheard of.

            You may not know this (just guessing because you commented on the nature of scripting/interpreted languages) but static analysis of dynamic languages has come really far and is an indispensable part of any reasonably sized project written in them these days. That’s another reason why I’m so surprised and frustrated by the lack of this in Python.

        • sqw@lemmy.sdf.org
          link
          fedilink
          English
          arrow-up
          0
          ·
          7 months ago

          cant practically anything throw an exception given the right (sometimes extremely remotely possible) circumstances?

          • prof@infosec.pub
            link
            fedilink
            arrow-up
            0
            ·
            7 months ago

            Not really. Exceptions are a controlled way of indicating something went wrong in an application.

            The only point where you wouldn’t know about the possibility of one is when you don’t know enough about the language features you’re using or when you use a badly documented library or framework.

            • sqw@lemmy.sdf.org
              link
              fedilink
              English
              arrow-up
              0
              ·
              6 months ago

              dont many of the language primitives confer the possibility of thrown exceptions?

        • Skull giver@popplesburger.hilciferous.nl
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          I’m not sure if the ability to tell would help. Just like typing hints are very much optional in Python, I don’t expect many libraries to get their exception declarations right. Especially if there are transitive dependencies

          I write Java code for my day job and while throws has been part of the language for ages, Java developers seem intent on avoiding it at all costs.

          I would welcome a throws in Python so that libraries and coworkers that do the right thing are easier to work with, but I don’t think it’d solve the underlying issue in most cases.

          • bjornsno@lemm.ee
            link
            fedilink
            arrow-up
            0
            ·
            7 months ago

            I believe raises is the de facto Python version of throws, but no tools seem to exist to actually handle it.

            • Eager Eagle@lemmy.world
              link
              fedilink
              English
              arrow-up
              0
              ·
              6 months ago

              that’s still a docstring, idk of linters that take docstrings into account at all. We need a semantic approach for this kind of annotation.

              • bjornsno@lemm.ee
                link
                fedilink
                arrow-up
                0
                ·
                6 months ago

                That’s way harder to ask for. A docstring solution is fine so long as the linters know to pick it up.

      • rwhitisissle@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        python guidelines

        Do you have a specific PEP you’re referencing or is this one of those “I assume this must be the case because of how common using try/except statements for flow control are” kind of things?

        • snekmuffin@lemmy.dbzer0.com
          link
          fedilink
          arrow-up
          0
          ·
          6 months ago

          Pretty sure its not a PEP, but the python glossary mentions it. Searching ‘python EAFP’ brings up a lot of discussion on the topic too, so if nothing else its definitely a widespread phenomenon

      • NeatNit@discuss.tchncs.de
        link
        fedilink
        arrow-up
        0
        ·
        6 months ago

        Like most things in life, context matters. In the OP it seems like the check function is used specifically so it could raise a PaymentException if the payment hasn’t been received… That’s not a “forgiveness/permission” context, this is a yes or no question, hence should have been an if.

    • wizardbeard@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      0
      ·
      7 months ago

      Still hurts, but sometimes it’s the only option.

      If you’re trying to confirm things like account existence/deletion, there’s often no “account exists” function to return true or false. You just have to figure out the specific exception thrown and catch that specific one.

      The worst are libraries that don’t give specific exceptions, so you have to catch all exceptions then do extra work to tell what the specific situation is. Does the account not exist, or is the system unreachable?

      • Ethan@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        ·
        7 months ago

        so you have to catch all exceptions then do extra work to tell what the specific situation is

        That’s horrifying. That’s a solid reason to avoid Python like the plague.

        • Lightfire228@pawb.social
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          While i also disagree with python’s tendency to use exceptions as control flow

          Python is a pretty stellar scripting language. I wouldn’t use it for app dev, but it’s quite handy for the odd automation or CLI task

          • Ethan@programming.dev
            link
            fedilink
            English
            arrow-up
            0
            ·
            7 months ago

            I’ve done a little bit of Python in the past, the biggest thing being an automation task that borderline became an app. I certainly can imagine using it for scripts, though I default to bash because that’s almost always available but TBH mostly because inertia. Beyond that my default is Go because inertia (and I love Go). I watched a video by the Primeagen (on YT) - in his view, Rust is better for text/data pipelines and CLI tools. Being very familiar with Go and not at all familiar with Rust, that’s an interesting take because honestly writing a CLI in Go is kind of meh.

      • prof@infosec.pub
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        Yeah, I had a similar case with some authentication middleware I used that was part of a library.

        It would always throw an exception when a user wasn’t authenticated instead of just giving me some flag I could check.

        Wouldn’t have done it that way, but it was okay for an API controller.