Le Friday 22 August 2008 15:03:21 Bruno Desthuilliers, vous avez écrit : > Maric Michaud a écrit : > > Le Thursday 21 August 2008 09:34:47 Bruno Desthuilliers, vous avez écrit : > >>> The point > >>> is that EAFP conflicts with the interest of reporting errors as soon > >>> as possible (on which much has been written see, for instance Ch. 8 - > >>> Defensive Programming in Code Complete), > >> > >> Defensive programming makes sense in the context of a low-level language > >> like C where errors can lead to dramatic results. In high-level > >> languages like Python, the worse thing that an unhandled exception can > >> cause is an abrupt termination of the process and a nice traceback on > >> screen. > > > > ... and leave your datas in inconsistent state. > > Not all applications persist data, so this is an application-specific > problem, to be solved at the application level - IOW, there's no > one-size-fits-all solution here.
... or lose open connection, reset sessions, etc.. it doesn't really matter what is lost when a program crash, if it can be restarted without changes it is hardly what I'd qualify a "dramatic result". It doesn't depend on the language what implications of an unhandled error are, It is always application-specific. > Anyway: transactions management is not > what I meant when talking about defensive programming. > > As far as I'm concerned, the only place where the defensive approach > really makes sense whatever the language is when dealing with external > datas (user inputs etc). > I agree, this is my whole point, "whatever the language is". > > So, what C or any other > > language could do worse to your application ? > > An error in a C program can do *way* worse than leave an application's > data in inconsistent state. See ART for more on this: > http://dialspace.dial.pipex.com/prod/dialspace/town/green/gfd34/art/ > I didn't read "dramatic results" in that sense, but with the meaning of a result that the program itself cannot handle. If the whole system crash due to an unhandled error in a program, once missile's dropped it doesn't really matter in which language it was written. Reliability of a system, as high-availability of an application, is mostly a problem beyond the scope of application level error checking. > >> In this context, defensive programming is mostly a waste of time > >> - if you can't *correctly* handle the exception where it happens, then > >> doing nothing is the better solution. > > > > If I don't buy the argument > > cf above - maybe you buy it after all ?-) > > > I actually agree with the conclusion. Each > > component of a program should try to manage only errors tied to their own > > logic and let pass others up to the gui logic for rendering errors the > > good way, persistence logic to rollback unwanted changes, and application > > logic to continue execution the right way. This is hard to do in C > > because you have no way to trap an error which happen randomly in the > > program, ie. a segfault will interrupt the execution anyway. > > Indeed. > -- > http://mail.python.org/mailman/listinfo/python-list -- _____________ Maric Michaud -- http://mail.python.org/mailman/listinfo/python-list