On 30 Sep, 11:14, TheFlyingDutchman <zzbba...@aol.com> wrote: > > > "in C I can have a function maximum(int a, int b) that will always > > > work. Never blow up, and never give an invalid answer. " > > > > Dynamic typed languages like Python fail in this case on "Never blows > > > up". > > > How do you define "Never blows up"? > > Never has execution halt. > > I think a key reason in the big rise in the popularity of interpreted > languages is that when execution halts, they normally give a call > stack and usually a good reason for why things couldn't continue. As > opposed to compiled languages which present you with a blank screen > and force you to - fire up a debugger, or much much worse, look at a > core dump - to try and discern all the information the interpreter > presents to you immediately. > > > > > Personally, I'd consider maximum(8589934592, 1) returning 1 as a blow > > up, and of the worst kind since it passes silently. > > If I had to choose between "blow up" or "invalid answer" I would pick > "invalid answer".
there are some application domains where neither option would be viewed as a satisfactory error handling strategy. Fly-by-wire, petro- chemicals, nuclear power generation. Hell you'd expect better than this from your phone! > In this example RG is passing a long literal greater than INT_MAX to a > function that takes an int and the compiler apparently didn't give a > warning about the change in value as it created the cast to an int, > even with the option -Wall (all warnings). I think it's legitmate to > consider that an option for a warning/error on this condition should > be available. As far the compiler generating code that checks for a > change in value at runtime when a number is cast to a smaller data > type, I think that's also a legitimate request for a C compiler option > (in addition to other runtime check options like array subscript out > of bounds). -- http://mail.python.org/mailman/listinfo/python-list
