How is it cavalier to be extremely clear on who is responsible for what in your code? When you code in one place is trying to second guess code in another that it can't control, that just leads to mess and no safety. That mess can cause confusion and real errors (such as the improper ignoring and swallowing of error messages in your code snippet).
My opinion is if you have a plugin system you have two sane options. The first is to trust that the plugin is coded properly. That will be the best option within most corporate code bases. The second is to build an explicit controlled security environment (eg a sandbox) and make sure the plugin in that environment. That is a lot of work and adds a lot of complexity but is sometimes necessary. However if you go that route, don't do it halfway. | [reply] |
When you load file names from a (corporate) config file, you can reasonably expect that they will exist and have the right permissions, but I'd still never omit the error checking on the open.
Even if your plug-in is written 'to spec', it can still cause exceptions, whether through coding error or coding design. Protecting your framework from errant plug-ins is such a simple step to take, it doesn't make sense not to.
Methinks you're arguing the man, not the issue.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Who is talking about loading file names?
I have a method call. One argument to that method call is an array of objects. Those objects will customize the return. They are supposed to support a specific API. If objects are passed in that do not implement the API they are supposed to implement, it is not the fault of my method that it was used wrongly.
As for causing exceptions, that depends on how your application handles exceptions. For many web based applications the most sensible thing to do is to throw up an error. Then handle it at the top level, for example by displaying a generic error page and then emailing the exception report somewhere. If this is your application design then you absolutely do not want to catch exceptions that you don't know how to handle.
Standalone desktop applications often take the reverse approach. They attempt to catch and recover from virtually every error. My experience suggests that taking this approach virtually guarantees a buggy application which silently fails in many ways. For example it fails because someone, somewhere, swallowed an important error message. Just like you did in your snippet. If your application domain takes you in this direction then OK, it takes you in this direction. But I'd prefer to work in application domains which handle errors in a less intrusive fashion.
| [reply] |
