Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!xlned.com!feeder5.xlned.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'sorts': 0.04; 'subject:module': 0.04; 'one?': 0.05; 'function,': 0.07; 'python': 0.07; 'exceptions': 0.09; 'from:addr:python': 0.09; 'list)': 0.09; 'none.': 0.09; 'scripts': 0.10; 'exception': 0.12; 'wrote:': 0.14; '(modifying': 0.16; 'answer,': 0.16; 'from:addr:mrabarnett.plus.com': 0.16; 'from:name:mrab': 0.16; 'message-id:@mrabarnett.plus.com': 0.16; 'received:84.92': 0.16; 'received:84.92.122': 0.16; 'received:84.92.122.60': 0.16; 'reply- to:addr:python-list': 0.16; 'result,': 0.16; 'shell': 0.19; 'wondering': 0.19; 'programming': 0.20; 'header:In-Reply-To:1': 0.22; 'do,': 0.22; '(and': 0.22; 'received:84': 0.25; 'expect': 0.26; "i'm": 0.26; '(in': 0.27; 'function': 0.27; "doesn't": 0.28; 'developers': 0.28; 'raise': 0.29; 'error': 0.29; 'functional': 0.31; 'to:addr:python-list': 0.32; 'example,': 0.33; 'bit': 0.33; 'generally': 0.33; 'module': 0.33; 'certain': 0.34; 'header:User- Agent:1': 0.35; 'module.': 0.35; 'reply-to:addr:python.org': 0.35; 'trigger': 0.35; 'list,': 0.36; 'considered': 0.36; 'should': 0.37; 'either': 0.37; 'andrew': 0.38; 'but': 0.38; 'errors': 0.39; 'returning': 0.39; 'to:addr:python.org': 0.39; 'would': 0.40; "it's": 0.40; 'best': 0.60; 'show': 0.67; 'reply-to:no real name:2**0': 0.72; 'header:Reply-To:1': 0.72; "can't.": 0.84; 'distinguish': 0.84; 'message?': 0.84; 'procedure,': 0.84; 'subject:handle': 0.84 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwHAJXQyk3Unw4S/2dsb2JhbACYEY1yd8g7hhAElBeKOw Date: Wed, 11 May 2011 19:08:57 +0100 From: MRAB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: python-list@python.org Subject: Re: Proper way to handle errors in a module References: <4DCAC78E.1000901@gmail.com> In-Reply-To: <4DCAC78E.1000901@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: python-list@python.org List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 27 NNTP-Posting-Host: 82.94.164.166 X-Trace: 1305137340 news.xs4all.nl 81484 [::ffff:82.94.164.166]:36790 X-Complaints-To: abuse@xs4all.nl Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:5145 On 11/05/2011 18:29, Andrew Berg wrote: > I'm a bit new to programming outside of shell scripts (and I'm no expert > there), so I was wondering what is considered the best way to handle > errors when writing a module. Do I just let exceptions go and raise > custom exceptions for errors that don't trigger a standard one? Have the > function/method return nothing or a default value and show an error > message? I'm sure there's not a clear-cut answer, but I was just > wondering what most developers would expect a module to do in certain > situations. Generally speaking, a function or method should either do what it's expected to do, returning the expected result, or raise an exception if it can't. Also, it's often clearer to distinguish between a function, which returns a result, and a procedure, which doesn't (in Python it would return None). For example, if you have a list, the functional form is: sorted(my_list) which returns a new sorted list, and the procedural form is: my_list.sort() which sorts in-place (modifying the list) and returns None.