Exception as the primary error handling mechanism?
lie.1296 at gmail.com
Tue Jan 5 18:10:27 CET 2010
On 1/6/2010 1:48 AM, r0g wrote:
> Steven D'Aprano wrote:
>> On Tue, 05 Jan 2010 13:06:20 +0000, r0g wrote:
>>> that's the case how can you expect it to validate anything at all in
>> The asserts still operate so long as you don't use the -O switch.
>>> Do you mean for debugging in situ or something? Could you
>>> maybe give me an example scenario to illustrate your point?
>> There are at least two sorts of validation that you will generally need
>> to perform: validating user data, and validating your program logic.
> <snipped very detailed and clear response, thanks :)>
> Cool, that's what I thought i.e. you can't rely on asserts being there
> so don't use them for anything critical but it's still a good idea to
> use them for logic/consistency checking in production code as, should
> you be running your production code unoptimised, it might catch
> something you'd otherwise miss.
Steven described the traditional approach to using assertions; another
approach to when to use assertion is the one inspired by
Design-by-Contract paradigm. DbC extends the traditional approach by
focusing on writing a contract (instead of writing assertions) and
generating assertions to validate the contract. Just like assertions,
these contracts are meant to be removed in production releases.
In Design-by-Contract, only codes that interacts with the outer-world
(e.g. getting user/file/network input, etc) need to do any sort of
validations. Codes that doesn't interact directly with outside world
only need to have a "contract" and simplified by *not* needing argument
checking, since the function relies on the caller obeying the
contract and never calling it with an invalid input.
DbC uses assertions spuriously, unlike the traditional approach which
is much more conservative when using assertions.
 or explicit language support which is just syntax sugar for assertions
 of course, on a debug release, the contract validation code will
still be enforced to catch logic/consistency bugs that causes the violation
More information about the Python-list