On 15Nov2013 14:08, Steven D'Aprano <steve at pearwood.info> wrote:
> On Thu, Nov 14, 2013 at 04:02:17PM -0800, Chris Barker wrote:
> > right -- any bugfix changes behaviour
>
> It isn't clear that this is a bug at all.
>
> Non-ascii Unicode strings are just a special case of the more general
> problem of what to do if printing the exception raises. If
> str(exception.message) raises, suppressing the message seems like a
> perfectly reasonable approach to me.
Not to me. Silent failure is really nasty. In fact, doesn't the Zen
speak explicitly against it?
I'm debugging a program right now with silent failures; my own code,
with functions submitted to a queue for asynchronous execution, and
the queue preserves the function result (or exception) for collection
later; if that collection doesn't happen you get... silent failure!
I think that if an exception escapes to the outside for reporting,
if the reporting raises an exception (especially an "expectable"
one like unicode coding/decoding errors), the reporting should have
at least a layer of "ouch, report failed, try something uglier but
more conservative". At least you'd know there had been a failure.
Cheers,
--
Cameron Simpson <cs at zip.com.au>
Windows is really user friendly - it doesn't crash on its own, it first
opens a dialog box, saying it will crash and you have to click OK :-)
- Zoltan Kocsi
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4