Martin v. Loewis: > However, now people say "I have followed this advise, and I got > banana software: matures at the customer. We would rather be certain > that the customer won't see exceptions that we never got in testing". > ... > Yes, it is these use cases: Somebody invokes an SQL method, which > happens to return a Unicode string, and then adds a latin-1 byte > string to it. It works for all ASCII byte strings, but then the > customer happens to enter accented characters, and the application > crashes without offering to safe recent changes. The problem here to me is that the failure is input data dependent so often hidden. There should be a way to remove this dependency on input data. Is there any way to specify that implicit conversions raise an exception? Perhaps by setting the default encoding to "undefined". Then these developers can find and fix their bugs before delivery to customers. Neil
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