as arguing against
exception handling per-se because exceptions can be less efficient. I
responded to correct that misconception. What the article really said
is that throwing an exception when none should be thrown is bad API
design, and inefficient to boot. I stand by that statement.
Cheers,
Michi.
--
http://mail.python.org/mailman/listinfo/python-list
ainly encounter the
first two conditions and, if there is no error, it will always
encounter the EOF condition. The fourth case is the unexpected one, in
the sense that this case will often not arise at all. That's not to
say that lost connections aren't routine; they are. But, when a
connection is lost, the program has to do different things and operate
on different state than when the connection stays up. This strongly
suggests that the first three conditions should be dealt with by
return values and/or out parameters, and the fourth condition should
be dealt with as an exception.
Cheers,
Michi.
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 1, 2:47 pm, Peng Yu wrote:
>
> In the article API Design Matters by Michi Henning
>
> Communications of the ACM
> Vol. 52 No. 5, Pages 46-56
> 10.1145/1506409.1506424http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
>
> It says "Anoth
On Thu, 9 Dec 2004, Duncan Grisby wrote:
> In article <[EMAIL PROTECTED]>,
> Michi Henning <[EMAIL PROTECTED]> wrote:
>
> [...]
> >Instead of compiling the definition, you can write:
> >
> >Ice.loadSlice("Color.ice")
> >import
would be created by pre-compiling the definitions).
Of course, the price you pay is a (small) delay during start-up because the
code is generated at run time rather than compile time.
Cheers,
Michi.
--
Michi Henning Ph: +61 4 1118-2700
ZeroC, Inc.http://www.zeroc.com
--
ht
