Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Comment on

( #3333=superdoc: print w/ replies, xml ) Need Help??
Doesn't sound like it to me. If it was, you'd just call the routine that produces an error message, and let that routine use its Big Switch Statement to decide how exactly to do that. (If the routine that prints an error message encounters an error while doing so, you'd probably consider that fatal and die.)

I think this part of the confusion might be due to the phrase "the routine that produces an error message". One of the advantages that exceptions give you is that there isn't a error handler, but multiple error handlers.

We don't want our low-level abstraction to have to know about the various ways its being used. We don't want our high-level abstractions to have to know about each other. If we have a single error handler then it has to know about every possible use. Every time we add a new way of handling the error we have to add it to our Big Switch Statement. Having to have one piece of code that knows about every possible usage is producing needlessly tight coupling between modules.

With an exception handling style error conditions and error handlers are separated. There is no "Big Switch Statement". Each error handler is local to the module that needs to handle an error condition in a particular way.

You can happily add new modules that handle the error in a different way without having to alter any other piece of code.

I'm starting to think maybe we're doing the same thing in opposite ways. You're reducing complexity by moving all knowledge of what's going on into the caller, and I'm reducing complexity by leaving the caller with knowledge only of what it wants to do with the data and moving all knowlege of where the data comes from into the subroutine. It may be a different paradigm.

I would characterise the difference as where you choose to handle the error.

  • You're proposing to handle the error where it occurs. This allows direct access to the "context" the error occured in. However the high level context (GUI vs CLI or whatever) has to be made available to the error handler in some way.
  • In exception handling you handle the error in the code that knows how to handle the error. This allows direct access to the high level context. However, the low-level context has to be passed to the error handler in some way.

Passing the high-level context down to the error handler is can be tricky. You've got globals, a Big Switch Statement, or you have to pass the calling context from the highest level down to the lowest level in some way (adding a special error handling object to every call for example). All of which (in my opinion) make the code harder to maintain - especially if you have a system with many layers and many possible error conditions and handlers.

There are, of course, some situations where you have to handle the error in the context it occurs in to be able to do anything useful. Some languages provide direct support for doing this sort of error handling cleanly (e.g. handler-bind in Common Lisp), but they provide exception handling too!

That said, in my experience, having to handle the error in the calling context of the routine that caused the error is rarely necessary.

Passing the low-level context up to an error handler is simple - it goes into the exception object when the error occurs.

In some ways, your approach reminds me very much of my brief experiments with the event-oriented paradigm when I took courses in two "fifth-generation" languages in college. As you probably know, event-orientation turns everything around by making user input the caller and the program's logic the callee. I have a bad taste in my mouth for this approach, possibly because the only languages I've used that do things that way are VB and Lingo, both of which I loathe, especially Lingo. Though now that I think of it, it might be possible to do something like it in Perl, sort of, and that might not be so bad. ponders this

Don't throw away event-handling because of VB & Lingo :-) It's a very useful coding style, and pretty much essential for many kinds of problem. Take a look at POE for one perl approach.


In reply to Re^2: Best Practices for Exception Handling by adrianh
in thread Best Practices for Exception Handling by Ovid

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others making s'mores by the fire in the courtyard of the Monastery: (9)
    As of 2014-11-27 16:13 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      My preferred Perl binaries come from:














      Results (186 votes), past polls