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.

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.

Who is talking about loading file names?

I was. Analogising that opening files from file names loaded at runtime is essentially similar to loading plug-ins No matter how well tested your set up, mistakes are made.

Just as you don't ignore error returns from open's you shouldn't be allowing exceptions within plug-ins to take out your framework. Even if the only sensible thing to do is report the error and die, better to trap it and do a controlled exit than trust to luck.

As for my snippet...that's exactly all it was. Basing arguments upon it is a blind as well you know.

---

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."