Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^9: eval to replace die?

by BrowserUk (Pope)
on Oct 04, 2010 at 19:24 UTC ( #863418=note: print w/replies, xml ) Need Help??


in reply to Re^8: eval to replace die?
in thread eval to replace die?

The caught() method in E::C 1.32 includes the type check: return unless blessed($e) && $e->isa( $_1 );

Yep! Same code. Which brings us right back to my first question way back up there.

What does isa() do?

This is what it does:

int Perl_sv_isa(pTHX_ SV *sv, const char *const name) { const char *hvname; PERL_ARGS_ASSERT_SV_ISA; if (!sv) return 0; SvGETMAGIC(sv); if (!SvROK(sv)) return 0; sv = SvRV(sv); if (!SvOBJECT(sv)) return 0; hvname = HvNAME_get(SvSTASH(sv)); if (!hvname) return 0; return strEQ(hvname, name); }

It check you've given it an sv, checks it's a reference; checks the refenced thing is an object; gets the package name from the stash where the object is stored; and then string compares that with the type-name string you passed in.

(And all of those same check will be followed when a reference is stringified!)

Now lets go back to where we came in with you saying:

If you're performing an exact match, a substring match, or a regular expression, any change to the text of that message in a subsequent release of Perl 5 could change the way your code behaves.

So are you now saying that exact matches are okay?

That its only regex matches that are "unreliable"? (Or are substring matches still verbotten?)

If so, why are you ignoring the ref versions that used string compare instead of the regex engine?

And why are you still insisting that Perl's regex engine is unreliable?

What all your snide asides and unstated implications resolve to, is that the regex engine is incapable of safely comparing strings.

Which you know is rubbish!

(And once again I'll ask you to post code so we can all test your assertions!)


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.

Replies are listed 'Best First'.
Re^10: eval to replace die?
by chromatic (Archbishop) on Oct 04, 2010 at 19:45 UTC
    What all your snide asides and unstated implications resolve to, is that the regex engine is incapable of safely comparing strings.

    You skipped over the simpler (and verifiable, per my use of the word "parsing" in my first post in this thread) implication that the unreliable part is writing good regular expressions which are not fragile in the face of simple changes to unstructured data. (That's the same reason many people suggest not parsing HTML with regular expressions, for example.)

      the unreliable part is writing good regular expressions which are not fragile in the face of simple changes to unstructured data

      Ah! Now we're getting some where. I'm going to assume that you don;t consider yourself incapable of writing a good regex; which by implication suggests that you assume that wonderful catch-all, "other people", can't.

      There's a really simple solution to that: regularise your error messages.

      You're already advocating moving your exceptions into a single file--the Exception::Class using exception declaration module.

      So, do the same thing with your error messages. And make them easy to parse:

      package MyModule::Errors; use constant { ERROR001 => 'MyModule::Error001: The frobwitz has a %d chance of r +eaching critcial mass", ERROR002 => 'MyModule::Error002: The doobry '%s' is frazzled', ... }; 1;

      Now all you need is:

      eval { somefunc() ); if( $@ =~ m[^MyModule::Error002] ) { ... };

      Simple. Lightweight. Reliable.

      Of course, now we're well on the way to returning error numbers instead of strings. And then providing a function (class method) that converts them to an error text (when required). With the added benefit of making I8N simple.

      Don't cover up simple design issues by layering heavy & complicated code over the top. Design a solution that addresses those issues at source. In this case, the source is the string form of the error returns, not the regexes the user needs to use to handle them.


      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.
      the unreliable part is writing good regular expressions which are not fragile in the face of simple changes to unstructured data.
      Ah, but at least it's possible.

      It's impossible to do plain string compare that isn't fragile in the face of simple changes. If

      $str eq "..."
      than any change to either of the strings, how minute, will make
      $str ne "..."
      which is, I think, the point BrowserUK is making.

      Whenever I write an exception system, I throw constants (or objects with a method returning such constants). Constants I export. So, if I were to change the value of a constant, the code would still run correctly (or at least, the programmer has to do some work to write code that doesn't run correctly on such a change). And if I were to change the name of a constant, there's a very high probability of the code no longer compiling. Then I can write code like:

      eval {....; 1} or do { given ($@) { when ($EXCEPTION1) {...} when ($EXCEPTION2) {...} default {...} } };
        Ah, but at least it's possible.

        Certainly. It's also possible for me to write a large Haskell program in one go which passes the type checker the first time, but I don't rely on that.

        It's impossible to do plain string compare that isn't fragile in the face of simple changes.

        Absolutely. Yet consider how classes and objects give you abstraction possibilities beyond which you can hide internal changes. That is, if you need to change your exception hierarchy in an incompatible way, you have the possibility of maintaining a compatibility layer between the old version (which can give a deprecation warning) and the new version.

        Bare strings don't give you that possibility.

        If you use—as I do—an exception system which uses roles to encode specific details about the type of exception then the only exact string comparison is to the name of the role and not any wording of the exception message. At some level in the system, something does have to compare a string to the name of a role yes, but that doesn't rely on any user having to craft the right regular expression which blends future proofing with accuracy.

        Whenever I write an exception system, I throw constants....

        Sure, I've seen that work well. Code which will only compile when it's correct is an advantage in these cases.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://863418]
help
Chatterbox?
[ambrus]: Hopefull the object isn't kept alive, the events are processed immediately, but you'd have to read a lot of source code to be sure about that.
[Corion]: ambrus: I think both of AnyEvent and Prima are pretty tight in their memory management because they both are cooperative multitasking and (I think) both use the Perl memory management for managing things
[Corion]: ambrus: And for Windows, I don't think that Prima knows if there still are messages queued for an object (in the Windows message loop). Finding that out would take lots of effort for little gain
[ambrus]: And even if this works, I'm still not sure you can't get double timeouts from a Timer.
[ambrus]: Corion: well Prima::Object says something like that the cleanup method will send an onDestory message and that you can't get more messages after cleanup, or something.
[Corion]: ambrus: Yeah - I don't think the deep source dive will be necessary if things are implemented as simple as they could be :)) And hopefully I won't need (more) timely object destruction. I can update the screen at 60Hz and hopefully even do HTTP ...
[Corion]: ... transfers in the background. Now that I think about it, this maybe even means that I can run the OpenGL filters on Youtube input :)
[ambrus]: Corion: I mentioned that the unix event loop of Prima always wakes up at least once every 0.2 seconds. Have you found out whether the win32 event loop of Prima does that too?
[Corion]: ambrus: Hmm - I would assume that the onDestroy message is sent from the destructor and doesn't go through the messageloop, but maybe it is sent when a window gets destroyed but all components are still alive...
[ambrus]: Corion: partly deep source dive, partly just conservative coding even if it adds an overhead.

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (8)
As of 2016-12-09 10:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    On a regular basis, I'm most likely to spy upon:













    Results (150 votes). Check out past polls.