Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^12: eval to replace die?

by phaylon (Curate)
on Oct 05, 2010 at 14:01 UTC ( #863607=note: print w/ replies, xml ) Need Help??


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

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


Comment on Re^12: eval to replace die?
Re^13: eval to replace die?
by BrowserUk (Pope) on Oct 05, 2010 at 14:16 UTC
    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.

      Have you head of Carp::Croak()?

      Have you read the word optional? Why are you ignoring all other of my points? If you don't have an actual argument but just want to be right then say so, and I'll just shut up.

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

      I disagree. Strongly.

      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.

      I disagree. First off, everything in programming requires discipline. Cooking and exception handling both require discipline, that doesn't make them identical. The big difference is that class namespaces are designed to be namespaces. Strings aren't. You can assume part of a string is a namespace, but you can never be sure. A class is always a namespace. It's designed for the job you want to cram into a string.

      You also say yourself why strings are less reliable for error handling: It's depending on your error message formatting, *plus* the handling of errors by a type you want to extract from a free-form value that might have come from anywhere. With objects, all you need to check is the type. It doesn't matter then how I format my errors, how you format you errors, how I format your errors and how you format my errors.

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

      With object oriented exceptions, there are the enforced standards of objects. Specifically that data and package are separate pieces of information that I can access reliably. And as I've said earlier, if you're the only programmer working the code, and never upgrade your modules, and know all formats of errors all other authors used, then yes, it might "work."

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

      Nothing will do that, but that's not an argument on the issue. I'd argue that inspecting user error messages for error type determination is bad code.


      Ordinary morality is for ordinary people. -- Aleister Crowley
        Why are you ignoring all other of my points?

        I addressed the only point I saw as relevant. Your "points" are not arguments; they are a fait accompli.

        In not so many words, your position amounts to: If it ain't object-oriented, it ain't right.

        You are of course welcome to hold that opinion, but there are other programming paradigms.

        And people were reliably handling errors and exceptions for many years before OO took hold of the collective imagination. And the techniques used then are still just as reliable as they ever were. Google for "ABEND" to see a system that been working just fine for a very long time.

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

        Nothing will do that, but that's not an argument on the issue.

        For me, it is the very crux of the issue. OO doesn't automatically fix all sins; and code does not have to be OO to be good or reliable.

        I'd argue that inspecting user error messages for error type determination is bad code.

        Worded that way, you're right.

        But omit two pernicious little words and you get: inspecting error messages for error determination".

        Which is exactly what has been going on in Perl, and many other languages, for decades. And perfectly successfully thank you.

        And your determination to see it as "bad code" just highlights your own blinkered outlook.

        And I'd argue that attempting to fix architectural problem by layering OO over everything, is the second most pervasive ill of the software industry today. It's not just "bad code", but bad education.

        Suggesting that :

        • the doSomething or die ...; idiom is always bad;
        • and that doSomething() or Some::Ridiculously:Long::Identifier->throw() is always good;

        is both: to deny history; and hopelessly naive.

        It's attempting to dictate a programming monoculture. And monoculture is bad in any field.


        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://863607]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (7)
As of 2014-12-22 07:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (112 votes), past polls