try:
[...]
except IOError:
# Worst-case scenario we can only catch errors at a granularity
# of the whole function.
[...]
else:
# If we have access to the source, we can silence errors on a
# per-expression basis, which is "better".
[...]
and then:
def __exit__(self, exc_type, exc_value, traceback):
# Returning True prevents the error from propagating. Don't silence
# KeyboardInterrupt or SystemExit. We aren't monsters.
I've been searching for something similar I saw years ago. It was a python library that would remove "heretical" code or something like that. Any error would be "eradicated".
It was funny! There was a religious or medieval theme or something. I can never find it...
In my previous life I was maintaining some backend services. One of the most common reasons for a service dying was a typo in a name in some rarely visited code path. I was tempted to write a similar module that would be a little bit smarter: when some identifier (variable, method, etc.) was not found, instead of raising an exception, try to find a similarly named thing and use that instead. I never did find a good way of implementing that.
I think you might like something like TheFuck?
EDIT: This bash commandline completion has been updated to by default wait for the user to verify the replacement command is what they wanted; this pretty much turns this from a terminal Russian Roulette into a kinda handy autosuggestion!
How about better testing and path coverage of your code? I hope that was also explored as a way to stabilize your codebase? Otherwise your suggestion does come offa bit as 'cowboy-ish' to say the least ...
That came from Smalltalk, where it was named doesNotUnderstand. It's always difficult to choose between crippling the language and encouraging stupidity.
There's debate in that thread whether this project is satire or not. I must admit it looks remarkably like satire, especially the test suite.
That said, I have met some developers who would find this as an advantage and might actually try to put it into use. Generally these are folks who prefer the default soldier-on-in-the-face-of-errors behavior from sh and perl.
> Generally these are folks who prefer the default soldier-on-in-the-face-of-errors behavior from ... perl.
Nobody in the Perl world prefers that, outside of people who are complete newbies. In fact, collectively Perl has been yelling at newbies for decades that anything not containing `use strict;` and `use warnings;` is almost without fail broken code, mainly because there are a lot of very old and outdated tutorials which introduce these modules as optional and/or way too late.
> Nobody in the Perl world prefers that, outside of people who are complete newbies
I think these are actually old-bies. They don't opt-in to `use strict;` because they like it that way. I suppose they just have an astonishingly high pain threshold.
To be clear here: You can be a perl newbie even after you've been writing Perl for decades. I know this because i sometimes see code like that in companies that don't value their employee education, or heck, their employee. Period. You'll have a guy who's been writing Perl for 15 years and never got past the small 500 word tutorial he once read back then. He may be old and have the years, but he's still a newbie since he doesn't know shit.
That said, i've never met these people outside of said companies and especially not on the internet and most decidedly not anywhere near any sort of perl community. They've all been strict 9-5ers for whom the coding is a burden to bear to pay the bills and nothing else.
The people who're old and in the community? They're on the same Kwalitee train as everyone else.
Ah, this leads to some of my favourite python bugs. Silent failures because you are catching and ignoring an error in some higher calling function where the error type that was once designed to deal with a single case is now overly broad. I've almost given up using try/catch for KeyErrors as a result.
Python uses try/except, not try/catch. The only reason to catch KeyError is to detect missing keys, so if you are trying to do that, only wrap your dict access rather than wrapping large blocks of code where anything could happen. If you are writing code to ignore errors, that is a bug in your own code, not a python bug.
But this tool is not meant to be used. You should never have to write
"import someReallyOffensiveModuleName" because those are jokes not meant to be used at work.
At work you should probably never be using a tool that just ignores errors. Errors are there for a reason, and you should have a very good reason for ignoring them.
def test_context_manager(): with fuckit: pass