in reply to Re^3: How to capture the "isn't numeric" warning?
in thread How to capture the "isn't numeric" warning?

For one, the signal handler will fire on any warning.

Yes, the same thought occurred to me ... but then I couldn't come up with an argument that could be passed to isNumeric() && elicit a warning other than the "isn't numeric" one.
Is there such an argument ?

Cheers,
Rob
  • Comment on Re^4: How to capture the "isn't numeric" warning?

Replies are listed 'Best First'.
Re^5: How to capture the "isn't numeric" warning?
by ikegami (Patriarch) on Jun 15, 2019 at 15:24 UTC

    You could get it from an object that overloads numification (0+) or int, and the sub handling the overload warns.

    One could argue that isNumber gives the better result in that situation.

      You could get it from an object that overloads numification (0+) or int

      Yes, that would do it.

      I did find a case where Scalar::Util::looks_like_number and the OP's isNumber return a different value for the same argument, but it had nothing to do with emission of warnings.

      For the arguments Math::MPFR->new(), Math::MPFR->new('nan') and Math::MPFR->new('inf'), Scalar::Util::looks_like_number will return FALSE, while isNumber will return TRUE.

      But this is probably the fault of Math::MPFR, which stringifies all values the same way as the mpfr library.
      And those 3 expressions therefore get stringified as "@NaN@", "@NaN@" and "@Inf@" (respectively).

      Math::MPFR probably should fix this by doing a s/@//g on the string prior to returning it. (And I'll attend to that.)

      I'll also mention that there's a perl API subroutine also named looks_like_number, but it doesn't look for any magic and therefore returns FALSE for most objects.
      Actually, I don't know of any cases where it will return TRUE for an object ... but I'm wary of asserting that such a case doesn't exist, or couldn't be constructed ...

      Cheers,
      Rob