Exception as the primary error handling mechanism?

Lie Ryan 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:
>>> If
>>> that's the case how can you expect it to validate anything at all in
>>> production?
>>
>> 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[1] 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[2] and never calling it with an invalid input.

DbC uses assertions[1] spuriously, unlike the traditional approach which 
is much more conservative when using assertions.

[1] or explicit language support which is just syntax sugar for assertions
[2] 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 mailing list