Exceptions vs Context Objects

[eric256]

I'm working on an extension of Module::Pluggable that builds in an Event/Trigger/Callback System. The event system allows all plugins to register for three slots of each event. I.e. calling the event "filter_html" will call it once for all plugins registered to handle it _before, once for _middle and once for _after. This seemed to give me some nice control and allow plugins to control exactly when they want to run. For instance if the plugin deals with cleaning up before the actual event then maybe it registers _before, while some might control the output and would therefore be after.

The Problem is that now sometimes a plugin might need to yell and say "stop processing other plugins at this level (before|middle|after)" and sometimes it might need to yell and say "hey we are dead in the water here so don't process any other plugins on this event." This is all fine and dandy so I set of with the idea to have magic return values. Immediatly this became a problem and had to be forgoten. So now i'm considering some alternatives. It would make sense if each plugin can edit the input and output, so that sounds like a context object, but i also want them to be able to abort which sounds like Exceptions.

The question then is....what do you think? I'm seeking some perl wisdom in this matter. I've never touched Exceptions and my experience with Context objects is that they are often a bit of extra code. Amy I missing something? Is this all a bad idea :) ? ... Thoughts, wisdom, guidance, stern yelling, and a swift paddle are all welcome.

Thanks in advance for any ideas.

[strat]

I'd use die (or croak) with eval-Block as well

It might be a good idea to standardize the error messages, e.g die "Error: $errorCode\t$message\n"; and write all the possible codes/messages at least into the documentation (or create a function/module which returns the error messages, e.g. like DBI::err(str)

[eric256]

I played with die, but didn't realy like messing with error codes as thats seemed a good source of typos. So i was thinking about using Error.pm instead. After sleeping on it, i think i want both Exceptions and a Context object to hand around. That way plugins can do thow Plugin::AbortEvent("Failed to load file") and use the context object/hash to pass around input and output variables.

[rjray]

Seems to me that the old stand-by of having the plugins/events call die, and having the dispatcher use eval when calling the event-handlers. Then you can catch the die's and react accordingly. And writers of these plugins can just use a familiar idiom to signal problems.

[tirwhan]

eval is exactly equivalent to the concept of catching exceptions in other (more pompous ;-) languages. What the OP is talking about is returning an exception object in $@ instead of just an error message. This object can then be inspected, modified and rethrown, or what have you, which gives a bit more flexibility in your error handling. Since this seems to be pretty much what the OP is after, I'd say yeah, exceptions are probably the way forward for this module.

[rjray]

I understand that. It's a matter of how complex he wants to make it for those that write the extensions. They can die with a string or with a blessed object. The advantage to the object approach is that he can also manage the "just how serious is this error" question, as well.

True exception handling is one thing I like about other (more pompous) languages. Sometimes I really miss it in Perl...

[educated_foo]

This looks like a perfect place for the under-appreciated nonlocal loop control operators, e.g.:

@sources = (
    { pre => [sub { print 1; }, sub { print 2; last pre; }, sub { prin
+t 3 }],
      post => [sub { print 4; }, sub { print 5; last source }] },
    { pre => [sub { print "badness" }] }
);

source: for (@sources) {
 pre: for (@{$_->{pre}}) {
        $_->();
    }
 post: for (@{$_->{post}}) {
        $_->();
    }
}
__END__
1
2
4
5

Document a good set of labels, and your module will be both convenient to use and educational about Perl's dark corners.

[idsfa]

I've seen a completely different approach to this problem in servlet filter chains (danger, java example). In this model, you create a container which holds the ordered list of steps. You can either do this with a linear model or a nested model.

In the linear model, an iterator over the container calls the first step, checks the results to see if it should continue, and passes the output to the next step until it is done. Pipeline is an implementation of this.

The java example above illustrates the nested model. Each step is passed the chain object, and is required to call the next step on the chain if and when it is ready to. In some implementations, it could also skip some or all of the remaining steps. In this model, each step is effectively nested inside the previous steps.