I’m working on a script of an alarm clock. I’m just finishing testing this section of the alarm clock front end. Every button works, controls which buttons are up or down as required and I have the state of the alarm settings when the ‘Set Alarm’ is pushed. So all is good UNTIL you push the ‘Set Alarm’ before you set a valid time, it shows an error because there is no new data yet for setting the alarm. All data is zero state meaning no alarm. The error is no alarm time set. As soon as you enter a valid alarm time all works fine.
I’m of two minds on this issue; one, I hate exceptions in my code. Two, are they trying to hack the clock, as there is no good reason to push set before pushing ‘Set Alarm’ button.
How to handle this? Ignore it as it should not happen and set up an exception, I don’t like it. I can flash a message about no alarm time set, asking for setting of the time before trying to set alarm.
EAFP. Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.
LBYL. Look before you leap. This coding style explicitly tests for pre-conditions before making calls or lookups. This style contrasts with the EAFP approach and is characterized by the presence of manyif statements.
In a multi-threaded environment, the LBYL approach can risk introducing a race condition between “the looking” and “the leaping”. For example, the code, if key in mapping: returnmapping[key] can fail if another thread removes key from mapping after the test, but before the lookup. This issue can be solved with locks or by using the EAFP approach.
Thanks for the great feed back. I found one other solution. To disable the ‘Set Alarm’ button until a valid time is in place. This removes the use of the button (button remains without text, just a colored button, no button movement and does nothing) and is made available as a working button with text when it is needed.
This is a good solution, and one you’ll see on a lot of web forms which
have validation.
Ideally it is occompanied by some indication of which fields are yet to
be filled out correctly. A simple thing is to set the outline of a field
to a distinctive “good” colour if it’s valid, though beware that
red/green colour blindness is common, so green-for-good and
red-for-bad/invalid may be a poor colour pair. Sometimes you need more
than just a colour if there’s syntax involved in the field contents i.e.
what syntax rule the bad input violates, and a list of the rules,
possibly as a “help” popup or mouseover text.
Let me highlight that last part: naive LBYL code can easily introduce a TOCTOU bug. This is not exclusive to multithreading - there are a lot of ways that you can fall foul of this (or fall fowl of it, when you chicken out and add a mutex around it). The LBYL approach can also sometimes simply do twice as much work - for instance, checking key in mapping has to look up the key to see if it’s there, and mapping[key] has to look up the key to see what value it has. Both of them have to cope with the possible absence of the key.
Use exception handling. It’s how Python was built. And the performance cost of a try block is extremely low, even zero in some versions of Python.
Cameron Simpson,
Thanks for all your help. Sure makes learning a positive experence.
I would like more information about color and what colors work best. What I would really like is, how do I find this information. I tried looking at what colors mean in different cultures. This is a new field to me. I was assuming that green was for go, start, and red for stop would be standard. See what assuming got me. lol
Really this is an important consideration, presentation to users. Lots to think about.
