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.
In reply to Re^7: Runtime introspection: What good is it?
by tilly
in thread Runtime introspection: What good is it?
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |