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."

If you're going to trap exceptions at the top level you should..trap exceptions at the top level. And nowhere else unless you have specific reason. So yes, there is error handling logic, but it is not in that specific module.

Opening files in Perl is different for a fairly important reason. If you're opening files you need to test the open and throw an exception because otherwise there is no exception to be caught and handled on the top level. In languages which automatically throw exceptions on failures to open files (eg Ruby) that code can go away.

If you're programming in Java then you have no choice but to note the existence of exceptions everywhere. It is my firm opinion that this is a design mistake in Java that encourages poor coding techniques.