Re: OOP php user system

On Mon, 10 Nov 2008 14:34:21 -0600, "Jessica Griego"
<jess@xxxxxxxxxxx> wrote in
<9V0Sk.5836$as4.3865@xxxxxxxxxxxxxxxxxxxx>:


"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message
news:gfa4co$ehj$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx

[snip discussion of properties as implemented in C#]

Foo f = new Foo();
if (f.setI(10)) {
...

Of course, if you want the try/catch block so you can handle it at a
higher level, you can always do something like:

if (!f.setI(11))
throw new System.InvalidArgumentException('Invalid value for i');

Or, it still allows you to do it in the function itself, ie.

public void setI(i) {
if (i > 0 && i < 10) {
m_i = i;
}
else throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
}

What's the difference between IF-ing a setter or trying/catching when
setting via normal OOP property 'syntax candy'? Not much...the words IF/ELSE
and TRY/CATCH maybe.

Actually, there are differences.

1. Each method of error handling lends itself to a different type of
code flow. Consider:

// Get user input

// Set the value of f.i
bool res = f.SetI(input);
if (false == res)
// User is inexperienced; take them to a wizard interface
else
{
// Ask for second input
res = f.SetI(input);
if (false == res)
{
// take path 1
}
else
{
// take path 2
}
}


You could do this with try/catch, but it might be a little ugly,
especially if the exceptions can only be identified by text strings.
On the other hand, using exceptions can make interrupting the flow of
code and bailing out much cleaner than a lot of if...else statements
or multiple returns:

try
{
// task one
// task two
// task three
}
catch (exception e)
{
// clean up all tasks, release resources and bail out
}

2. Exceptions generally have far worse performance than returning a
simple value, because they must unwind the stack, capturing
information as they go.

The big problem is that C#'s implementation limits you as to how you can
do it (if you use their property methods).

You need to qualify this with a real-world example, Jerry. As it is, that
statement is a load of hog-wash!

No, Jerry's right, as far as it goes. If you use properties, the only
way that you can handle invalid input is to throw an exception. It
does limit your options. Whether that's a problem or not depends on
the architecture of the application and the needs of the particular
class and attribute. I don't agree with Jerry that it's inherently
bad design.

As for your example - you can easily have a method which does the
calculations for you, i.e

iTeachersPerStudent = Class.GetTeachersPerStudent().

But why does he need to? What's the compelling argument to do that?

Class.TeachersPerStudent as a property is just fine. It is also far more
clear to the caller when it is a read/write property than if everything is
treated as a function prefixed by either get or set. And also, please tell
me the 'i' in iTeachersPerStudent isn't the amateurist's mistake of using
hungarian notation...right?!!!

Hungarian notation, as originally invented by Charles Simonyi, was
intended to indicate the use of the variable with a prefix (e.g. the
prefix "cb" was for "count of bytes"). In the Microsoft world, it
quickly morphed into something to indicate the type of the variable.
While opinions on this usage vary widely, it is quite common in that
arena. I can assure that it's usage in no way designates the user as
an amateur, any more than variable_names_with_underscores indicate
professionalism.

--
Charles Calvert | Web-site Design/Development
Celtic Wolf, Inc. | Software Design/Development
http://www.celticwolf.com/ | Data Conversion
(703) 580-0210 | Project Management
.

Relevant Pages

  • Re: How expsensive in terms of performance is try / catch
    ... Both of your examples have the same number of try/catch blocks. ... if each try/catch block reduced performance, ... try/catch blocks that simply eat exceptions are bad. ... your own code, but you can't avoid dealing with them altogether, and ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: new without delete: what will happen
    ... If you're writing try/catch a lot, you're probably not using exceptions ... The idea is to have destructors of local objects perform ...
    (microsoft.public.vc.mfc)
  • Re: Exception handling?
    ... try/catch is bad, which it usually is. ... clauses you have and the effectiveness with which you're using exceptions. ... I once wrote code for an OS that threw an exception when an API failed. ... Part of the problem is that not everything is encapsulable in RAII. ...
    (microsoft.public.vc.mfc)
  • Re: [PHP] Try{} Catch()
    ... shouldn't rely on try/catch for algorithm implementation. ... You create exceptions for errors and unexpected behavior. ... and/or sending an error message to the user. ... try/catch works great for small/medium projects, ...
    (php.general)