Bruce Sass wrote: > What do you do when you want boolean data from a remote site, but the > link is down. You could give up and wait for the link to come back, > use a hardcoded default, or defer to something else which returns a > value you can use. All I did was include the definition of what to do > in the boolean class so the three cases could be handled as such: Actually, I found the best mechanism for my needs, when I did something like this, was to have an object with a five-state value (definitely, probably, maybe, probably not, and definitely not), a textual message, and a level above which this would be considered "true" if all you wanted was a boolean. So if, for example, you were checking an email address, you could do something like definitely - email got delivered probably - final machine was down, but email got queued on an MX host maybe - email got queued locally, address is syntactically valid probably not - heuristics fixed the address and it queued OK ("1234,567" -> 1234.567 at compuserve.com) definitely not - Couldn't figure out what the email address was. Then, for this, you'd likely set the "ok" level at "maybe", meaning "maybe or better should be treated as success", but you could still check the details, with the text string available for logging/debugging. Just a class I found myself using all *over* the place when doing failure-prone internet stuff. -- Darren New / Senior MTS & Free Radical / Invisible Worlds Inc. San Diego, CA, USA (PST). Cryptokeys on demand. schedule.c:7: warning: assignment makes calendar_week from programmer_week without a cast.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4