• Closely integrated messages and exceptions properties. I wanted to be able to assign values to properties and have the message autogenerated based on those property values. The code for it is really quite simple, but for some reason, none of the modules consider this terribly important. Not only does this save time and typing, it also makes it much easier to retrofit the code with localized messages: just stick the property values into a new language specific format string.

• The thread id at the time the message is generated.

• Chained exceptions. Sometimes what a low level module considers important about an exception is not what a higher level module considers important. When that happens I want to create a new exception with a more relevant error message that "remembers" the exception that inspired it so if need be, I could see the entire history from origin to destination.

• The ability to see propagation history (where an exception is rethrown) and not just the chain of calls that were made to get to the original place the exception was generated.

• A stack trace that tells me what subroutine the problematic code of line is located in rather than what subroutine was called on the problematic line. If I'm scanning a chain of calls, I want to see the context where the problem occured not just a pinhole view of the actual line where the problem occured.

• A stack trace that won't lie to me about the parameters that are being passed to subroutines. I know it is impossible to recreate the actual values in the parameter list because the parameter list for any sub is just @_ and that can be modified when a programmer uses shift to process command line arguments. The most the DB module can give me is the way @_ looked at the time the next frame in the stack was set up. Still most stack traces are formatted as if they are showing the actual parameters passed to the sub rather than what was left of them by the time the next stack frame was set up.

  If the programmer used my ($arg1, $arg2,...) = @_ and never used shift or anything else that modifies @_ it will just happen to be the values passed to that subroutine. But often subroutine arguments are processed with shift and by the time the next subroutine is called, @_ is stuffed with a bunch of leading undef's. It no longer looks like it did when the sub was originally called. Why not just tell me it is the value of @_ at the time the next frame was created so I don't think I passed a heap of undef's to my subroutine? Better yet, provide me some sort of visual hint that those undefs might be bogus so I don't have to do that extra thinking step each time I see them. I want to focus on the code, not on remembering the quirks of Perl stack tracing.

• An uncluttered stack trace where I can easily control the amount of detail and won't have error messages truncated (a problem with Carp::croak). Sometimes being able to see what subroutine was calling what other subroutine will tell me everything I need to locate the bug. I don't always want to see chained exceptions, the propagation sequence or even what's left of @_ at the time the next frame in the stack was generated. In fact, that is true most of the time. All I need is a simple list of what called what on which line of which file.

• Can shed its OOPishness and still be useful when someone tries to handle it and doesn't know or care what sort of exception it is. I want it to be used as a string in string context. I want it to be well behaved in equalities and compare reference addresses. It needs to be thrown and rethrown using normal Perl symantics, e.g. die $myerr to throw and die without parameters to rethrow.

On my less important but still nice list:

• A way of declaring exceptions that doesn't make me bunch them all up in an ugly hash at the top of my script. Call me fussy but I find the way that Exception::Class wants me to declare exceptions ugly and unwieldy.
• No fixed base class with obscure subclassing semantics. I want to control the heirararchy of my exceptions.