[bind10-dev] Exception speed

David W. Hankins dhankins at isc.org
Thu Oct 8 21:13:52 UTC 2009


On Thu, Oct 08, 2009 at 03:08:52PM -0500, Michael Graff wrote:
> I believe this means, to me anyway, that we raise exceptions only when
> they really are exceptions, and not just when we can't do something.
> That is, suppose we had a "read this file, and if it exists, parse it."
>  We could code this to attempt to open a file, and if it's not there,
> raise a FileNotFound() exception, otherwise process it (which might
> raise a ParseError() exception.)  While we won't call that sort of
> things rapidly, perhaps it is best to return something indicating that
> no file was read, and leave the ParseError() there if there is an actual
> parse error.
> 
> A lame example, perhaps...

Sticking with the example however, surely parse errors in existing
files are much more frequent than non-existing files?

I think the lesson is that exceptions really should be exceptional.
They aren't a primary data path.

Another example we raised earlier in BIND 10 design discussion was
the idea of producing "packet parsing backtraces", and there was an
example we could use exceptions for these.

But "receiving a flood of bogus packets" is something that has a
performance criteria...and may not actually be exceptional.

Is that a better example?

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20091008/d47bb7ac/attachment.bin>


More information about the bind10-dev mailing list