Re: RFC: A better name for an exception handling module?

Replies are listed 'Best First'.
Re^2: RFC: A better name for an exception handling module? by ELISHEVA (Prior) on Dec 28, 2010 at 06:39 UTC
Thanks! I really like this name. It does succinctly capture the main benefits: Bug context: The stack trace's main feature is that it more clearly shows the context of the problem Programmer context: The integration of messages and properties means that exception creation takes better advantage of information available to the programmer. The programmer does not need to restate things in more than one place. End user/development context: The ability to retrofit/add locality support with a minimum of advanced planning means you can better fit the exceptions to changing development contexts and end user needs Are there downsides to this name? Right now, it is coming down to a tie between Tilly's suggestion and the original name Exception::Lite due to Jethro's observations about "Lite" being an important selling point. The job of a good name isn't to be "cool" but to attract the people who will eventually want the package enough to download it. In theory you can sell something with any name, but when the name and the product are mismatched it is a lot more work. What is the difference between a person who would click through to `Exception::Lite` vs. `Exception::Context`? Which name would attract the people who would end up downloading it?	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: RFC: A better name for an exception handling module?
by ELISHEVA (Prior) on Dec 28, 2010 at 06:39 UTC

Thanks! I really like this name. It does succinctly capture the main benefits:

Bug context: The stack trace's main feature is that it more clearly shows the context of the problem
Programmer context: The integration of messages and properties means that exception creation takes better advantage of information available to the programmer. The programmer does not need to restate things in more than one place.
End user/development context: The ability to retrofit/add locality support with a minimum of advanced planning means you can better fit the exceptions to changing development contexts and end user needs

Are there downsides to this name? Right now, it is coming down to a tie between Tilly's suggestion and the original name Exception::Lite due to Jethro's observations about "Lite" being an important selling point.

The job of a good name isn't to be "cool" but to attract the people who will eventually want the package enough to download it. In theory you can sell something with any name, but when the name and the product are mismatched it is a lot more work. What is the difference between a person who would click through to Exception::Lite vs. Exception::Context? Which name would attract the people who would end up downloading it?

[reply]
[d/l]
[select]