Reply to thread

Message: [QUOTE="Chris Angelico, post: 5097392"] (Out of curiosity, which language? Feel free to not answer, or to answer off-list, as that's probably not constructive to the thread.) I cannot name a single modern programming language that does NOT have some kind of implicit boolification. The only such language I know of is REXX, which has a single data type for everything, but insists on the exact strings "1" and "0" for True and False, anything else is an error. Every other language has some definition of "these things are true, these are false"; for instance: * C-family languages treat all nonzero integers as true * Shells treat 0 as "success" and nonzero as "error", and therefore as "true" and "false" respectively (yes, this IS an inversion) * Pike allows any variable to contain the integer 0, regardless of its declared type, and thus is a sort of "null" value which is false; all strings, arrays, mappings, etc are true * Python treats an empty "thing" as false and a nonempty one as true SQL is like REXX in that it's fairly strict; a condition must be a boolean (example from PostgreSQL): rosuav=> select 1+2 where 1; ERROR: argument of WHERE must be type boolean, not type integer LINE 1: select 1+2 where 1; ^ But an explicit conversion is permitted: rosuav=> select 1+2 where cast (5 as boolean); ?column? ---------- 3 (1 row) The looseness doesn't preclude critical applications. It's all a question of what you're testing. Does your code care that this be a list, and not something else? Then test! You have that option. What happens if it isn't a list, and something is done that bombs with an exception? Maybe that's not a problem. Critical applications can often be built in layers. For instance, a network server might listen for multiple socket connections, and for each connection, process multiple requests. You would want to catch exceptions at the two boundaries there; if a request handler crashes, the connection should not be dropped, and if a connection handler crashes, the server should keep running. With some basic defenses like that, your code need no longer concern itself with trivialities - if something goes wrong, there'll be an exception in the log. (BTW, this is one of the places where a bare or very wide except clause is appropriate. Log and move on.) ChrisA [/QUOTE]

Verification