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

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."
  • Comment on Re^8: Runtime introspection: What good is it?

Replies are listed 'Best First'.
Re^9: Runtime introspection: What good is it?
by tilly (Archbishop) on Jul 14, 2008 at 22:29 UTC
    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.

      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.
        I'm referring to the module that I discussed in Re: Runtime introspection: What good is it?.

        For example in one place in my current reporting framework I have a way that objects from lots of modules can be passed into a particular method in another module. There are several useful methods that they might implement. When I load the first module I don't know what others might exist and I don't know what will be passed in, so I leave the decision as to whether to call the method to run time where I check that the method exists by calling can, and then do one thing if it does and another if it doesn't.