Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Be more OO with "Class" modules?

by chunlou (Curate)
on Jul 30, 2003 at 23:15 UTC ( #279413=note: print w/ replies, xml ) Need Help??


in reply to Be more OO with "Class" modules?

If I use something like Error unilaterally in a project, or if some people write a module in an exception-handling way, the others in a good old Perl-ish way, it marginalizes the collective effectiveness. That's why there's a tendency towards using the common denominator. This is not a functionality issue but a language issue.


Comment on Re: Be more OO with "Class" modules?
Re: Re: Be more OO with "Class" modules?
by chromatic (Archbishop) on Jul 30, 2003 at 23:40 UTC

    If I write tests in a project and other people don't, it marginalizes their and my effectiveness. If you're working with other people on a project, you should have coding standards. This is not a language issue, it's a playing-nicely-with-other-people issue.

      That's a good way to look at it. There could be coding standards if it's a within company project, not when we're taking over a project from someone else. try-catch block like that isn't a most common coding style in Perl.
Re^2: Be more OO with "Class" modules?
by adrianh (Chancellor) on Jul 31, 2003 at 00:16 UTC
    This is not a functionality issue but a language issue.

    It's not a language or a functionality issue. It's a development team issue. In any project it will be best to pick a common error handling mechanism. This is true no matter what language you choose.

    If you have multiple people on a team using different coding styles that's a team problem, not a language problem.

    Beyond that it's not really an issue. It's trivial to wrap code that handles errors via return values so that it throws exceptions (e.g. Fatal). It's trivial to wrap code that throws exceptions to return errors (via eval {}).

    Personally I would recommend using exceptions since I find they have many advantages. However, this is an issue for your development team to decide after weighing the pros and cons.

    Exceptions are also completely separate from OO. You can, if you wish, have an exception handling system with just plain strings (although I wouldn't recommend it).

    The try/catch syntax supplied by Error has some problems as perrin has already pointed out. However this has to do with prototyping/blocks/closures rather than exception handling in Perl. All the other modules do is provide some syntactic sugar for declaring exception classes and throwing exception objects.

    There is nothing special about these classes and objects - they're just normal Perl objects. Exception handling is a core part of Perl and you shouldn't worry about using it if it's appropriate for your project. For many kinds of Perl applications (e.g. DBI) exceptions are really the only way to go.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://279413]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (8)
As of 2014-07-25 04:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (167 votes), past polls