 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / Perl / Modules / July 2008Name space: throwing exceptions easily
Hello everybody, I am developing a module to make throwing Exception::Class objects easier. The goal is to make the code to throw an exception shorter and to make it possible to keep all error messages at some central place. The module works quite similarly to Class::Accessor and provides a function mk_exception_functions that puts the required functions into a given namespace. For example you can define an exception like __PACKAGE__->mk_exception_functions (messages => {foo => 'Error foo occurred.'}, exception_class => 'Exception::Class::Mine'); and later just call foo() if($foo); instead of Exception::Class::Mine->throw(message => 'Error foo occurred.') if($foo); Currently the module uses the package Exception::Class::EasyThrow but I don't know if this is really a good name. It is a bit vague and rather refers to the intended use of the module instead of what it does. I would be happy about other suggestions. Thanks a lot, Lutz How about Exception::Easy ? > Hello everybody, > I am developing a module to make throwing Exception::Class objects [quoted text clipped - 25 lines] > Thanks a lot, > Lutz Hi sawyer x, thanks for your suggestion. On Sun, Jun 29, 2008, sawyer x wrote: > How about Exception::Easy ? The idea to put it out of the Exception::Class name space is definitely worth considering because my module can in fact deal with any class that implements a throw method and I am planning to make it still more flexible in a future version. However, Exception::Easy sounds too much to me as if it would implement yet another exception framework which is not the case. I hope to find something more descriptive of what the module does. Thanks for your input, Lutz I've personally noticed that a lot of modules use an Easy subspace to show it's an interface or ability that's stripped down and made simple for you. I think this would be your emphasis. That you haven't written a new framework, but present an easy way to use the existing ones. For example: IO::Pty::Easy which uses IO::Pty. Maybe a different keyword you would be interested (which seems popular) is *::Simple. For example: CGI::Simple (which uses CGI.pm), SVK::Simple (which uses SVK.pm). This is just how it would seem to me if I were looking for a simple exception handler that makes using exceptions easier. > Hi sawyer x, > thanks for your suggestion. [quoted text clipped - 13 lines] > Thanks for your input, > Lutz * Lutz Gehlen <lrg_ml@gmx.net> [2008-06-28 13:55]: > The module uses the package Exception::Class::EasyThrow > but I don't know if this is really a good name. It seems fairly reasonable to me. Putting it inside the Exception::Class:: namespace seems better than not; but once you accept that, the problem is that any name you pick is inevitably going to be quite long. The only suggestion that occurs to me is the File::Spec vs File::Spec::Functions precedent, which would suggest Exception::Class::Functions for your module. Regards,  SignatureAristotle Pagaltzis // <http://plasmasturm.org/> Hello Aristotle, thanks for your feedback. > * Lutz Gehlen <lrg_ml@gmx.net> [2008-06-28 13:55]: > > The module uses the package Exception::Class::EasyThrow [quoted text clipped - 4 lines] > once you accept that, the problem is that any name you > pick is inevitably going to be quite long. The last reply of sawyer x convinced me that the "Easy" extension is maybe not so bad. Exception::Class::Easy would also be a bit shorter than EasyThrow. Thanks, Lutz Hi Lutz, * Lutz Gehlen <lrg_ml@gmx.net> [2008-06-30 20:30]: > The last reply of sawyer x convinced me that the "Easy" > extension is maybe not so bad. personally I find ::Easy and ::Simple no more useful than ::Foo. It says absolutely nothing about what kind of ease or simplicity I can expect, and CPAN has plenty of examples of such modules exhibiting all possible interpretations of these words. (XML::Simple comes to mind here, which has an API so complex at this point (with its own strict mode!) that the name is almost comical.) * Lutz Gehlen <lrg_ml@gmx.net> [2008-06-30 20:45]: > My module installs functions because I see an exception as > something that belongs to a package. However, I already thought > about also offering an mk_exception_methods function for people > who prefer to throw an exception with a method call. […] But I > had not thought of using import, it's a nice idea. You’ve seen Sub::Exporter? Regards, SignatureAristotle Pagaltzis // <http://plasmasturm.org/> If I may... personally I find ::Easy and ::Simple no more useful than ::Foo. > It says absolutely nothing about what kind of ease or simplicity > I can expect, and CPAN has plenty of examples of such modules [quoted text clipped - 3 lines] > this point (with its own strict mode!) that the name is almost > comical.) This just screams to me like we need to have better standards than canceling out words English language that can be used to mean something. Instead of ruling out the words Easy, Tiny, Simple, Fast, and any other word, we need to have better standards to make sure these words are still meaningful to us. It'd be easier to have a new module up called Log::Fast and have it take 30 minutes to actually log something, thus ruining he idea of ::Fast, but it'd be more worthwhile changing its name to Log::FsckingSlow and not ruin ::Fast. And it would be even better to just do it right altogether and make Log::Fast justifiable. Also, it's just hit morning here, so... good morning! :) * sawyer x <xsawyerx@gmail.com> [2008-07-01 08:10]: > > personally I find ::Easy and ::Simple no more useful than > > ::Foo. It says absolutely nothing about what kind of ease or [quoted text clipped - 18 lines] > even better to just do it right altogether and make Log::Fast > justifiable. You utterly missed the point, though arguably I made it in a misleading way. I did *not* say that XML::Simple isn’t simple. The point is that “simple” in “XML::Simple” means “parses XML documents into plain Perl data structures” rather than “has a simple API” or “consists of simple code” or some other kind of simplicity. I am *not* saying that you should avoid certain words because they might become lies. *Any* word can be a lie. I am saying that “simple” has so many different meanings that it doesn’t actually say anything useful. If I see a module called Exception::Easy in a list of modules, I have *absolutely no idea* what it does. In contrast, if it was Exception::Class::Functions, I could immediately guess pretty well at what it does, even if I didn’t know exactly. Regards, SignatureAristotle Pagaltzis // <http://plasmasturm.org/> > If I see a module called Exception::Easy in a list of modules, > I have *absolutely no idea* what it does. In contrast, if it was > Exception::Class::Functions, I could immediately guess pretty > well at what it does, even if I didn’t know exactly. I take it the opposite way. Exception::Class::Functions makes no sense to me. Class? Functions? What? In the end, I will have to click through and read the docs. The name is meaningless and hard to type. As for Exception::Easy, I think that makes a lot of sense. "Oh hey, a simplified interface for dealing with exceptions." I will still have to click through and read the docs, though. Additionally, Exception::Easy will only show up when searching for "exception", while Exception::Class::Functions will show up when searching for "class" and "function" in addition to "exception". Exception is really the only relevant keyword, so why contaminate the already-busy "Class" search with something that's not relevant? In the end, I can't think of any module names that make sense without knowing what they are. A few words aren't enough to describe a module in detail. If you are faced with 10 search results that sound relevant, you will just have to click through and skim the docs. Even if the module does what you want, the interface might not be what you want, or you might dislike the implementation. For example, compare Moose to Class::Builder. Both are class builders, but the better-named one is *not* the one you want to use. I think Shakespeare said it best: What's in a name? that which we call a rose By any other name would smell as sweet; The converse is also true. Regards, Jonathan Rockway Signatureprint just => another => perl => hacker => if $,=$" * Jonathan Rockway <jon@jrock.us> [2008-07-02 18:30]: >> If I see a module called Exception::Easy in a list of modules, >> I have *absolutely no idea* what it does. In contrast, if it [quoted text clipped - 5 lines] > to click through and read the docs. The name is meaningless and > hard to type. Fair enough. We can reasonably disagree on whether Exception::Class::Functions is a good name. That’s neither here nor there. Personally I don’t like it a lot, just better than the other options on the table so far. > As for Exception::Easy, I think that makes a lot of sense. "Oh > hey, a simplified interface for dealing with exceptions." I > will still have to click through and read the docs, though. On this, I disagree. Here’s litmus test: would you ever use the opposite adjective in a description? If not, it’s not useful. I think you’ll agree that no one would call a module Exception::Complicated except as a joke. That means “easy” provides no useful differentiation in practice. In fact, the “simplified” in “simplified interface” is largely redundant. Using an interface by definition means you are looking for simplification in doing or accessing the thing that the interface provides. Similar words that say something without communicating anything are “fast” and “flexible.” No one would say that they are trying to achieve slowness or inflexibility. In all of these cases, there is a tradeoff that you are accepting to gain, say, simplicity at the cost of inflexibility, or maybe flexibility at the cost of simplicity, or flexibility and simplicity both at the cost of performance, or whatever the particular tradeoff happens to be. > Additionally, Exception::Easy will only show up when searching > for "exception", while Exception::Class::Functions will show up > when searching for "class" and "function" in addition to > "exception". Exception is really the only relevant keyword, so > why contaminate the already-busy "Class" search with something > that's not relevant? Because anyone who searches on “class” gets what they deserve. :-) > In the end, I can't think of any module names that make sense > without knowing what they are. A few words aren't enough to [quoted text clipped - 3 lines] > want, the interface might not be what you want, or you might > dislike the implementation. I see a trend here… you are the person who argued loudly that in the end, anyone who wants to know how Catalyst works needs to read the code, regardless of the state of the docs… > I think Shakespeare said it best: > > What's in a name? that which we call a rose > By any other name would smell as sweet; > > The converse is also true. Whoohoo, let’s just call it NinjaCamp then (it produces functions that throw fatal errors, geddit, geddit?). Naming is hard, let’s go shopping. Maybe you want to (re-?)read Zen of Comprehensive Archive Networks sometime. Then again, you are the author of a Catalyst-based weblog app called Angerwhale, which makes me wonder if you haven’t long forfeited your right to take part in *any* discussion about naming. :-P Regards, SignatureAristotle Pagaltzis // <http://plasmasturm.org/> * Aristotle Pagaltzis <pagaltzis@gmx.de> [2008-07-03 00:25]: > In fact, the “simplified” in “simplified interface” is largely > redundant. Using an interface by definition means you are [quoted text clipped - 10 lines] > or flexibility and simplicity both at the cost of performance, > or whatever the particular tradeoff happens to be. Err, I forgot to finish my argument. Where I was going with this is that it is this tradeoff that is meaningful, and that is what you want to describe in a summary such as the name of a module. Regards, SignatureAristotle Pagaltzis // <http://plasmasturm.org/> > * Aristotle Pagaltzis <pagaltzis@gmx.de> [2008-07-03 00:25]: >> No one would say that they are >> trying to achieve slowness or inflexibility. Drafted any mission-critical change control policies recently? # from Aristotle Pagaltzis # on Wednesday 02 July 2008 15:21: >no one would call a module Exception::Complicated except as a >joke. Well, you're going to have a hard time predicting what a gaggle of zany programmers might do, especially if you dare them like that ;-) I, for one, am seriously looking forward to the opportunity to publish Exception::Complicated::Er. >That means “easy” provides no useful differentiation in practice. That much is true. Except it does imply that the author thought something about the problem space was overly difficult, which might resonate with the audience. >Whoohoo, let’s just call it NinjaCamp then That's a snazzy name, but doesn't really fit since ninjas might conjure up associations such as "sneaky assassins for hire" -- I would like my exceptions to be more straightforward and loyal. Possibly Samurai::Picnic or Berserker::Expedition. Or just Grenadier. --Eric SignatureDon't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- * Eric Wilhelm <scratchcomputing@gmail.com> [2008-07-03 02:00]: > # from Aristotle Pagaltzis > # on Wednesday 02 July 2008 15:21: [quoted text clipped - 8 lines] > I, for one, am seriously looking forward to the opportunity to > publish Exception::Complicated::Er. That’s the “as a joke” clause. I made very sure not to forget that qualification. ;-) Regards, SignatureAristotle Pagaltzis // <http://plasmasturm.org/> > On this, I disagree. > [quoted text clipped - 3 lines] > joke. That means “easy” provides no useful differentiation in > practice. I don't think this tests what you think it tests. People don't name their module Foo::Complicated because they don't want to admit the interface is complicated. People *do* call modules Foo::Easy because they're proud that they made Foo easy. So the module naming here reflects the author's personal or societal hangups, not the validity of any naming scheme. > In fact, the “simplified” in “simplified interface” is largely > redundant. Using an interface by definition means you are looking > for simplification in doing or accessing the thing that the > interface provides. Easy means "less features to learn". Ever use XML::LibXML? It's big. It's hard to get started with it. If you just wanted to XPath some XML string, you might like a module like XML::LibXML::Easy to exists. Instead of creating a parser, parsing a "balanced chunk" into a "document fragment", initializing the XPath engine, adding some namespace, running the query, and then printing the returned nodes; you might just want to say 'xml("<foo>")->xpath("//foo")->stringify'. That's not nearly as complex as XML::LibXML, so why not call it "Easy"? Of course, you lose a lot of power with that API. Tradeoffs. > Similar words that say something without communicating anything > are “fast” and “flexible.” No one would say that they are trying > to achieve slowness or inflexibility. Usually the slow/inflexible version comes first, so it gets the base namespace. If history could be rewritten, then the slow version would be replaced with the fast one... but that's not always possible, especially with how CPAN.pm works. Basically, the names of CPAN modules are hacks around CPAN itself. > I see a trend here… you are the person who argued loudly that in > the end, anyone who wants to know how Catalyst works needs to > read the code, regardless of the state of the docs… I'm not sure why this upsets so many people. If you want a complete understanding of every detail of a codebase, you have to read it. You're not going to get any better at programming if you never read code. This is what I believe and I'm going to stand by it. (If you don't want to be good at programming, that's fine with me. Give me some money and I can solve your programming problems for you :P) Anyway... if you don't want to read the code, I hear there's a whole book about Catalyst. > Then again, you are the author of a Catalyst-based weblog app > called Angerwhale, which makes me wonder if you haven’t long > forfeited your right to take part in *any* discussion about > naming. :-P Modules and applications have different naming standards. I think most of my modules have names that make sense. I can't think of any applications I use that have names that make sense, however. "emacs" for editing text? "amarok" for playing music? "urxvt" for emulating terminals? "irssi" for chat? None of those names make any sense at all. So I don't feel like I'm alone in coming up with weird-a.s names for things :) Names for modules need to be somewhat related to what they do, but you probably shouldn't devote too much mental energy to coming up with a name. It's just not *that* important. (Opaque identifiers)++ Regards, Jonathan Rockway Signatureprint just => another => perl => hacker => if $,=$" * Jonathan Rockway <jon@jrock.us> [2008-07-03 19:35]: > Of course, you lose a lot of power with that API. Tradeoffs. Which is, as I said, what you want to communicate. > So I don't feel like I'm alone in coming up with weird-a.s > names for things :) That was tongue-in-cheek anyway, hence the razz smiley. :-) Regards, SignatureAristotle Pagaltzis // <http://plasmasturm.org/> # from Lutz Gehlen # on Saturday 28 June 2008 04:51: >__PACKAGE__->mk_exception_functions > (messages => {foo => 'Error foo occurred.'}, > exception_class => 'Exception::Class::Mine'); > >and later just call >foo() if($foo); This requires you to inherit from the exception class, but it installs functions instead of methods? If the only call needed is mk_exception_functions(), that could just be import(). --Eric SignatureIssues of control, repair, improvement, cost, or just plain understandability all come down strongly in favor of open source solutions to complex problems of any sort. --Robert G. Brown --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- Hello Eric, > # from Lutz Gehlen > # on Saturday 28 June 2008 04:51: [quoted text clipped - 7 lines] > This requires you to inherit from the exception class, but it > installs functions instead of methods? In fact, it does not inherit from Exception::Class. Exception::Class is not a classical class itself after all but offers via its import function to define subclasses of Exception::Class::Base. My module installs functions because I see an exception as something that belongs to a package. However, I already thought about also offering an mk_exception_methods function for people who prefer to throw an exception with a method call. > If the only call needed is mk_exception_functions(), that could > just be import(). Well, the reason against that is the mk_exception_methods function I just mentionend. But I had not thought of using import, it's a nice idea. Thanks for your feedback, Lutz # from Lutz Gehlen # on Monday 30 June 2008 11:43: >> If the only call needed is mk_exception_functions(), that could >> just be import(). > >Well, the reason against that is the mk_exception_methods function I >just mentionend. But I had not thought of using import, Yes, even in the case of creating methods, this could be done with options to import() rather than requiring the caller to inherit you as a base class. If you can possibly avoid requiring inheritance as an interface to these sorts of meta-class tools, it allows the user more flexibility in defining their class hierarchy and eliminates the risk of method name clashes between the meta and their own parent class. Extra points if you implement unimport(), which means the caller can say 'no Meta::Thing' so that the functions only exist at compile-time. This eliminates all risk of cryptic, tricky, and unexpected run-time errors from method-lookup name clashes. --Eric Signature"But as to modern architecture, let us drop it and let us take modernistic out and shoot it at sunrise." --F.L. Wright --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.