Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Now there’s an interesting idea: don’t make bare except illegal, make it have an implicit raise at the end (and disallow return, break, and continue).

https://discuss.python.org/t/pep-760-no-more-bare-excepts/67...



...ahh, a bit of a misreading on my part. However, I was really looking for your explanation of the horrors that could happen rather than what the suggestion was. Thinking through a bit more, yeah, implicit re-raise does have some pretty bad outcomes if you can't change code in a dependency.

It still feels like `deno` is somewhat on the right track where permissions are dropped by default, but It'd Be Nice(tm) if programming languages enabled that a bit easier.

    import sales_tax_calculator as xyz with [ cap.NETWORK, cap.FILESYSTEM, cap.USB, ...etc... ]
    xyz.calculate( sales_price, state=user.address.state )
We're implicitly allowing imported libraries the full power of the containing programming language where with promiscuous code sharing (trending towards a low-trust environment), it'd be a lot better to _not_ give `cap.FS, NETWORK, USB, etc...` by default.

Bringing it back around: `import somelib with [ cap.BARE_EXCEPT, cap.RAISE ]` or something to control their handling of "unknown" exceptions is interesting. Let them handle any exceptions or interrupts they've authored, but let me explicitly have control over catching stuff that isn't "from them".

...an extended version of dependency injection or inversion of control.


Adding an implicit raise to the end of a bare-except would quietly break things, and is non-trivial to detect. Say you have a naive base-except:

    def loop():
        try:
            check_service()
        except:
            logging.exception("Error while checking service.")
            time.sleep(60)
        
Really you shouldn't be using a base-except here. You should at the bare minimum catch `Exception`. Adding an implicit `raise` at the end will break this function without so much as a warning. Instead of calling the function every minute, the loop is broken with an unexpected exception that was deliberately suppressed (and logged).

A more common scenario for myself is write a lot of my scripts in the style:

    def main(argv: list[str]) -> int:
        # Parse args, setup logging, etc.

        try:
            run_script(args)
        except:
            log.exception("Script failed.")
            return 1

        return 0

    if __name__ == '__main__':
        sys.exit(main(sys.argv))
An implicit raise would obnoxiously break them when my bare-except is intentional, and effectively cause the error to be printed twice to the terminal. Now I'm not wholly opposed to forcing `except BaseException:` instead of `except:`, but an implicit raise would cause all sorts of subtle bugs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: