in reply to Re^6: Runtime introspection: What good is it?
in thread Runtime introspection: What good is it?

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.

  • Comment on Re^7: Runtime introspection: What good is it?

Replies are listed 'Best First'.
Re^8: Runtime introspection: What good is it?
by BrowserUk (Patriarch) on Jul 14, 2008 at 21:30 UTC
    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.
[reply]
      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.

[reply]
        So yes, there is error handling logic, but it is not in that specific module.

        I'm not sure what you mean by "that specific module", since neither of us has mentioned any 'specific module'. Wherever you are envisaging (assuming) I'm doing my exception handling, is almost certainly different to where I'm envisaging doing it.

        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]

In Section Meditations