http://qs1969.pair.com?node_id=863592


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

Chromatic suggested that using exceptions avoided "unreliable string comaprisons, substring comparisons and regexes". Which it doesn't. It just moves them.

Yes it does. It's not the string comparisons and regular expression matches that are unreliable. It's the process of determining the type of an error by the representation of it (the message).

For example, if you check if the error starts with "Foo", I will break your exception handling by throwing any error that starts with "Foo". That can't happen if the type of the error is carried externally to the representation shown to the user. And an object with a class is just that kind of an error. If you throw a MyError::Foo, I would have to explicitly throw that error or a subclass of it for it to be recognised by your error handling.

Handling errors by message inspection works fine as long as you're the only developer in the code base. And never upgrade.

Ordinary morality is for ordinary people. -- Aleister Crowley

Replies are listed 'Best First'.
Re^11: eval to replace die?
by BrowserUk (Patriarch) on Oct 05, 2010 at 13:35 UTC
    If you throw a MyError::Foo, I would have to explicitly throw that error

    And if I prefix my error messages with "MyError::Foo" you'd have to explicitly throw an error that started with that string to break my error handling.

    And if two modules chose bad namespaces--like MyError rather than MyModuleName::Error--then the same problem arises in code that uses both modules.

    The error vectors are exactly the same! It's still just string compare.

    The solution is in well chosen namespaces--whether error prefixes or execption class names.

    Just moving to throwing exception objects rather than strings does not fix the underlying problem: that of badly chosen namespaces!

    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.
[reply]

      And if I prefix my error messages with "MyError::Foo" you'd have to explicitly throw an error that started with that string to break my error handling.

      Right, which can happen a lot, since I don't prefix my errors and often build error messages dynamically. So if my error is "MyError::Foo instance cannot be passed to do_something()", your error handling breaks. And it doesn't even do it consistently, it'll break depending on what I want to communicate to the user.

      Yes, bad namespaces are a problem. But there's no namespaces in error messages. It's all just a message. And while you can define for yourself that the start of the message is "the namespace," I'd rather use inheritance, since that has dedicated namespace functionality.

      Again, exception objects are for communicating with the rest of the program. Error messages are for communicating with the user. If you mix the two, there's worlds of pain down that road. Not to mention the fact that exception objects can carry optional stack traces and various other information, which makes them even more valuable to the user, even if it's just to communicate a better description of the error to a developer.

      If you really think $foo eq "bar" and $foo->isa('Something') are exactly the same, I'm quite concerned.

      Ordinary morality is for ordinary people. -- Aleister Crowley
[reply]
        Not to mention the fact that exception objects can carry optional stack traces and various other information, which makes them even more valuable to the user, even if it's just to communicate a better description of the error to a developer.

        Have you heard of Carp::Croak()?

        If you really think $foo eq "bar" and $foo->isa('Something') are exactly the same, I'm quite concerned.

        If you think that $foo eq 'Something' and $foo->isa( 'Something' ) are vastly different...you should be concerned.

        The bottom line is, either technique requires programmer discipline. If you really used 'MyError' for your exception namespace, you are just as vulnerable to someone else choosing that badly chosen namespace for their exceptions, as I would be if I used a non-specific formating convention for my error messages.

        If programmers adhere to a standard for their errors or exceptions, the problems are alleviated.

        But exceptions are not a magic bullet that will fix badly architected code.

        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.
[reply]
[d/l]

In Section Seekers of Perl Wisdom