[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Understanding exceptions



Hi,

Tilo Schwarz <list@tilo-schwarz.de> wrote:

> Hi together,

[...]

> here). For me, KISS would be more like that:

[ piece of code ]

> But, as always, it's a matter of taste...

I agree that your way of coding this particular algorithm is relatively
elegant. I said in another message that I would have done this way if
there would have been a bit more different message types. It's a fuzzy
threshold problem as when to deploy a generic machinery or not.

While your way is nice, many people will still prefer the one I first
proposed because this instruction:

        appli.update(dict(zip(msg["fieldnames"],
                              fieldvalues)))

is relatively complicated to understand (you probably know that Guido
has thought many times about removing built-in some functions that lead
to functional-style coding such as zip, map or reduce---don't remember
which ones, though; this because he thinks they often decrease the
readability of the code and thus should be replaced by explicit loops).

In my own projects, I generally write things the way you proposed,
because I like the elegance of the generic "formula", so to speak. In
that particular project, I was time-constrained (I said it was
closed-source code!) and couldn't always code the way I would have in a
free software project. But the end result was still easily readable and
worked very well, anyway.

I think my point is still valid: the purpose of the code sample was to
show an algorithm where different cases are handled that can generate
similar exceptions, so the error handling code can be factored out in
the exception handler, leaving the main code with only the logic bits.
In the example I gave, the different cases where not that different, so
you managed to write a generic handling routine for them, but I'm pretty
sure every reader that is not as stubborn as Andrew can figure out a
case where it is virtually impossible (or at least ugly) to have a
generic handler for each specific case, yet some errors generated by
their execution can be managed at an upper level. And in this case,
having exceptions makes the code shorter and does not pollute the logic
with similar error handling statements all the way.

Regards,

-- 
Florent



Reply to: