3 ms·
It depends on the problem domain. If you've got very tightly controlled inputs, it's not unreasonable to expect tightly-bound results (like the last example in
by mceachen 7y ago
It depends on the problem domain.
If you've got very tightly controlled inputs, it's not unreasonable to expect tightly-bound results (like the last example in the article).
If you're writing intermediary code between unsafe inputs and other libraries, there might be a reasonable boundary to catch all unknown errors and wrap as a failure.
In PhotoStructure's case, it's an easy solution: I simply don't import the given file. There may be a similar reasonable boundary in your problem space.
- shadowgovt 7y agoAgreed. And sometimes, the right solution is to assume inherently unsafe code and do one's best to guarantee safe behavior anyway. Operating systems and web browser tab isolation, for example, operate under this principle (as do many web servers that use multithreading to support multiple requests in the same process, so that one bad request doesn't deny service to N hundred completely unrelated user sessions). ... but if one is doing that, one should do it very explicitly. I prefer a codebase that separates regular flow of operation from the "catch-all" or "panic-recover" loops that indicate "The buck stops here for catastrophic failure."