Exception as the primary error handling mechanism?

[Phlip]

On Jan 5, 5:01 pm, Chris Rebert <c... at rebertia.com> wrote:

> > Why can't int('nonnumeric') return None?
>
> Errors should never pass silently.

You are saying I, as the programmer, cannot decide what is an error
and what is a pass-thru. The decision is made for me. (Yes yes I can
write int_or_None(), etc...)

Here's a super easy example:

  { 42: 'forty two' }.get(41, None)

Because I can supply a default, I can decide what is an error and what
is .

Now the equivalent in a language that does not enjoy this false "Zen":

  { 42: 'forty two' }[41]  # returns None
  { 42: 'forty two' }.fetch(41, None)  # ibid
  { 42: 'forty two' }.fetch(41)  # raises an exception

The quicky validation is available if I _request_ it.

> Quibbling over a mere one more line of code (or writing one short
> function) seems a bit petty.

Because that "Zen of Python" is an empty sophistry that forces me to
add a "mere one more line of code" over and over again...

> > (A related question - why can't I just go 'if record = method():  use
> > (record)'. Why extra lines just to trap and assign the variable before
> > using it?)
>
> I believe that's disallowed so as to prevent the subtle bugs seen in C
> code which result from when someone makes a typo and omits the second
> "=" in their `if foo == bar():` test.

Don't prevent me from using a technique just because others had
trouble with it.

And if bar() == foo is the superior technique anyway, because the ==
happens in chronological and lexical order after the bar() call.