Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re^12: eval to replace die?

by mithaldu (Monk)
on Oct 08, 2010 at 12:32 UTC ( #864195=note: print w/ replies, xml ) Need Help??


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

> Exception::Class doesn't avoid string comparisons, it just moves them elsewhere;

I think this is a misinterpretation on your side.

Chromatic is not arguing against string comparisons per se, but against converting complex structures (errors) into strings which then need to be parsed back into complex structures in other places. He is arguing against this in comparison to the possibility of just passing complex structures as they are and only convert them to strings when actually needed.

E::C is really only one way to do it. Just plain throwing hashes as exceptions makes things nicer because you can add things to them without any risk of breaking regexes when converting back to a complex structure on inspection.

At least that's how i read what he's saying.

As far as a workable example goes, what would be wrong with this: http://gist.github.com/616705 (updated to be more amenable to classic perlers)


Comment on Re^12: eval to replace die?
Re^13: eval to replace die?
by BrowserUk (Pope) on Oct 08, 2010 at 15:31 UTC
    I think this is a misinterpretation on your side.

    Chromatic is not arguing against string comparisons per se, but against converting complex structures (errors) into strings which then need to be parsed back into complex structures in other places.

    And I think that misinterpretation lies elsewhere. I do understand Chromatic's point, but I think my point is equally valid. If not stronger as it happens earlier in the scheme of things: that is, earlier in the execution order.

    Take this

    use Exception::Class ( 'MyException', ^^^^^^^^^^^ + #1 'AnotherException' => { isa => 'MyException' }, ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^ + #2 & 3 'YetAnotherException' => { ^^^^^^^^^^^^^^^^^^^^ + #4 isa => 'AnotherException', ^^^^^^^^^^^^^^^^ + #5 description => 'These exceptions are related to IPC' }, 'ExceptionWithFields' => { ^^^^^^^^^^^^^^^^^^^ + #6 isa => 'YetAnotherException', + #7 ^^^^^^^^^^^^^^^^^^^ fields => [ 'grandiosity', 'quixotic' ], alias => 'throw_fields', }, );

    There are seven, unchecked points of failure in that small sample. Those strings eventually end up in the symbol table, which is a hash.

    Later, when the exceptions are thrown; and later still when they are caught and isolated, a lookup into symbol table will be done to find them--and that is a string comparison.

    If there are typos in any of those 3 places; or if the exact name of one of them is changed, accidentally or deliberately at some later point in the development or maintenance cycle; then a mismatch occurs. But because they start life as strings, those errors won't show up until runtime. As these are by definition, only exercised in exceptional circumstances, that could be months or even years later before the mismatch is discovered in production.

    Now, as this is Chromatic we're talking about, I'm sure--had he not disengaged(*)--that he would argue that those failure paths should be exercised during pre-production unit & systems testing. And he would be right.

    But exactly the same holds true for any failures in the parsing of exception strings! In both cases, either the code is tested and errors are caught before production; or they're not and they turn up in production.

    And when the mismatch is detected, there will be just as many places to change in the E::C class code as in the string error code--assuming equal diligence to the DRY principle on behalf of both developers.

    E::C is really only one way to do it.

    That was the original basis of my contention. eval & die is a legitimate other way; that has been acceptable to Perl programmers for the best part of 20 years; and is used, where needed, by 18,000+ (-60 that use E::C) CPAN modules.

    I've no objection to people re-inventing the wheel, but mandating change for change's sake, is intolerable.

    Recommending a heavy & broken(see below) replacement, even worse.

    Just plain throwing hashes as exceptions makes things nicer

    That's fine--if you actually need complex structure--which is debatable. But does no one see how easy and lightweight that can be done:

    eval{ die { a=>b=>c=>d=>}; } or print %{ $@ };; c d a b
    because you can add things to them without any risk of breaking regexes

    I think that I've demonstrated above that the "risk" is no greater that with E::C, if you assume equally diligent developers and testing regimes. To assume otherwise is either naive or prejudicial.

    when converting back to a complex structure on inspection

    And this is the final sinew on my bone of contention. Why do you need structured information to deal with an exception?

    If you are going to deal with by trying to 'fix' it, then you will (should) be at a point in the code where you already have access to all the required information to do so. There should *never* be an occasion when the failing routine has to pass you information to deal with an exception that you don't already have access to. After all, you called the routine and passed it the relevant information!

    And if you are going to deal with it by reporting an error; you only need to log the string form anyway. The most you need to do is prefix it with something like:

    An error occurred.

    The following information probably won't mean anything to you, but it will greatly help our developers to provide you with a quick solution. Please report it accurately.

    blah...

    Or, if you feel the need to keep the technical details from your customers, display a "user friendly" message of the form:

    An error has occured. Please pass the full details, from error message timestamped: "yyyy-mm-dd hh:mm::ss Error123" in the program log, verbatim to our developers, along with as much other information as possible, for a speedy resolution.

    and log the text of the exception.

    Most of the time, I see no technical reasons to extract complex information from an error message. And that really squashes the main argument for structured exceptions. Which makes mandating their universal use nothing more than jumping headlong on the Java-esque bandwagon and pandering to the latest fad.

    As far as a workable example goes, what would be wrong with this: http://gist.github.com/616705

    Um...apart from that it wasn't available until 5:30am today, which means my searches--nor anyone else's--could have found it at the point I did my searches; it uses Try::Tiny. Which may be a good way to do it, but isn't mentioned in the E::C synopses, and essentially throws away the purpose of half the code including two of the dependencies of E::C.

    The module synopsies use:

    # catch if ( $e = Exception::Class->caught('MyException') ) { warn $e->error, "\n", $e->trace->as_string, "\n"; warn join ' ', $e->euid, $e->egid, $e->uid, $e->gid, $e->pid, $e +->time; exit; } elsif ( $e = Exception::Class->caught('ExceptionWithFields') ) { $e->quixotic ? do_something_wacky() : do_something_sane(); } else { $e = Exception::Class->caught(); ref $e ? $e->rethrow : die $e; }

    Which to the best of my abilities, simply doesn't work!

    (*) And I take his early disengagement from this discussion, to mean that these realities have dawned upon him also.


    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.
      Alright, i'll give it one more try to see if i can get through to you. Here's how the situation looks like to me:

      <chromatic> errors like "Error:ID:001|description|extradata:eins,zwei,drei" are terrible, because if you parse them with regexes, shit is hilariously easy to break in ways that are hell to debug or worse, you won't even NOTICE
      <BrowserUK> but with exception objects you still have to compare strings, SO THERE!
      You completely miss the crucial difference between a simple string comparison and a regex to deparse something. The former is fine because that's what perl even does when calling builtins, because they are ALSO in a hash table. The latter is a nightmare when you're dealing with inputs that are bound to change.

      That was exhibit one. But there is more to come.

      Um...apart from that it wasn't available until 5:30am today
      The module synopsies use: ... Which to the best of my abilities, simply doesn't work!
      My example is a cut-down version of the synopsis, with some things changed to make it more readable for perl developers who are really adverse to thinking about things. Furthermore, the synopsis works. You can dump it into a .pl file, add a hashbang at the top and execute that and it will just plain work.

      Have you even tried that or did you let your prejudices guide you?

      essentially throws away the purpose of half the code including two of the dependencies of E::C.
      E::C's code consists of two files:
      Class.pm - a factory for exceptions
      Class/Base.pm - a base class with all the things exceptions can do

      Its depencencies are:
      Class::Data::Inheritable = 0.02
      Devel::StackTrace = 1.20
      Scalar::Util = 0
      perl = 5.008001

      So, seriously, what the hell are you talking about? Neither of this has an overlap with Try::Tiny.

      There should *never* be an occasion when the failing routine has to pass you information to deal with an exception that you don't already have access to. After all, you called the routine and passed it the relevant information!
      You have never worked in a team where components are written by different people.

      eval & die is a legitimate other way; that has been acceptable to Perl programmers for the best part of 20 years; and is used, where needed, by 18,000+ (-60 that use E::C) CPAN modules.
      Do you think Justin Bieber is an amazing artist and provides rich value to the human culture? (Hint: Appeal to popularity is a fallacy.)
      But does no one see how easy and lightweight that can be done: die %hash
      Yes, i did that for a while. It's nicer than strings, for reasons explained at the top, but it's also a bit clunky and makes you type a lot of stuff. I ended up having to boilerplate a lot when throwing exceptions like that, so having a module that provides a bunch of that kind of stuff in one is neat.

      Now, one point i have to concede: The API for E::C is a bit atrocious, and forces you to also do a lot of boilerplating. Thus: http://www.reddit.com/r/perl/comments/domue/rfc_simple_callerbased_exception_creation/
        Alright, i'll give it one more try to see if i can get through to you.

        There is no need for you to "try to get through" to me. I understand what you (and others) are saying. I just disagree with your conclusions, and I've tried (hard) to present my reasoning in detail. You can either accept or reject my reasoning, but re-stating your flawed position over again will not change my reasoning, nor my conclusions.

        You completely miss the crucial difference between a simple string comparison and a regex to deparse something.

        No I didn't. But you apparently didn't read half my post, because it you had you have read the bit where I showed that there is no good reason to "deparse" the error string.

        "Exhibit one" fully rebutted!

        Have you even tried that

        Of course I did, but the synopsis code, all in a single file, is not useful. So I tried and posted a realistic example. It doesn't work:

        C:\test>exceptions 1 0 Can't locate object method "throw" via package "MyExceptions" at C:\te +st\exceptions.pl line 8.

        I invited corrections, none were forthcoming.

        My example is a cut-down version of the synopsis, with some things changed

        And the things you changed mean that you're not using half of the functionality of the module. You don't use either of the ->throw() or the ->caught() methods. You use Try::Tiny for this functionality, presumably because you couldn't get them to work either.

        BTW: E::C throw() and caught(), and Try::Tiny's use of die and catch{} are overlap!.

        (Hint: Appeal to popularity is a fallacy.)

        Statements of verifiable fact are not "appeals to popularity"; and by definition, cannot be "fallacy".

        Do you think Justin Bieber ...

        Who?


        Further restatements of our respective positions serve no purpose. Let's just accept that you think I'm an idiot; and I think that you are too caught up in trying to suggest that I am, to have bothered to read what I've written and make any real attempt to apply logic to it.

        I'm done.


        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 take his early disengagement from this discussion, to mean that these realities have dawned upon him also.

      Not in the least; I tired yet again of wiping your spittle from my screen. The word mandate? I assure you: I look nothing like Moses and I have no stone tablets in my office.

        The word mandate?

        A reference to the perl-critic default.


        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://864195]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2014-08-31 01:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (294 votes), past polls