in reply to Re^2: (in cleanup) Can't call method "close" on an undefined value at somePerlModule.pm line number.
in thread (in cleanup) Can't call method "close" on an undefined value at somePerlModule.pm line number.

thanos1983:

If you just want to fix that line, you can do it like this:

sub DESTROY { my $class = shift; return if ${^GLOBAL_PHASE} eq 'DESTRUCT'; $class->{handle}->close() if defined $class->{handle}; }

However, as mentioned elsewhere, $class->{handle} is *only* used in your destructor, so it's not really a useful line of code. Then, going backwards through the destructor, there's nothing happening that needs to be done. So removing the destructor would be the correct solution. But since you said it's a sample of your code, you might've removed a subroutine or two that could potentially set the handle member. In that case, this change should clear things up for you.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

  • Comment on Re^3: (in cleanup) Can't call method "close" on an undefined value at somePerlModule.pm line number.
  • Download Code

Replies are listed 'Best First'.
Re^4: (in cleanup) Can't call method "close" on an undefined value at somePerlModule.pm line number.
by thanos1983 (Parson) on Jan 30, 2015 at 22:38 UTC

    Hello roboticus,

    Thank you for your input, this is my first time coding in OO way and I do not know how to do it correctly. I am reading online documentation and I am trying to figure it through there.

    So one final question, when is needed to use a Destructor?

    Seeking for Perl wisdom...on the process of learning...not there...yet!

      If for example, your class uses a database, the destructor would be a good place to close the connection.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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". I'm with torvalds on this
      In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

        If for example, your class uses a database, the destructor would be a good place to close the connection.

        Yup, but DBI connections already come with a destructor that closes the connection, so :)

        Another use scenario is to break circular references, but those are easily avoided with https://metacpan.org/pod/Scalar::Util#weaken

        Yup, in perl, I've rarely written a destructor

      If you wanted to warn if the close failed

      thanos1983:

      Typically you only need a destructor when you're using a resource that perl can't figure out how to release automatically.

      I don't recall ever needing to use a destructor in perl, but the situations I can think of are typically things like having circular references that don't get freed automatically. Generally, though, my code doesn't worry about that, because between perl and the operating system, when the script ends, all the resources will be closed and freed.

      I don't have any suggestions on how to recognize when you need one--but another monk might have a few. If it were me, I'd ignore destructors until you get more comfortable with learning OOP. Once you get a good handle on it, you'll probably start to figure out when destructors make sense.

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.