Exception Management Question

[The Crow]

we dont live in stone age, there is almost no "not graphical" but User
Interface type. users dont interact with applications via mors alphabet sort
of things.

 

[The Crow]

after save button is pressed, you retrive a coherent business object. and
what do you do with it? who changes its properties? do you just call Save
method and leave it?

 

[Jeff Louie]

Crow... Then I would argue that you must explicitly state the
precondition.

// ASSERT value.length >15
public string Name
{
get{return name;}
set
{
if(value.length > 15)
throw new ArgumentException("Name's length cannot be more then
15");
name = value;
}
}

Regards,
Jeff

 

[The Crow]

no i meant, after ui call Validate() and not a null value returned, ui %99
will take an action.

and those tests should offer the possibility of calling a
validation
routine rather than having to handle an exception.

you have to deal invalid conditions, whether an exception is thrown, or
Validate returns not a null value.

 

[Bruce Wood]

Well, in the case of one of my applications, which maintains
information for our company, the Save method persists it to the
database. I then include it in my local cache of valid objects. I could
equally well have reloaded that list from the database, but for speed
reasons I don't do that in this app.

If the user then wants to edit the object some more, I pass the object
back into the corresponding validator, which raises events back out to
the UI layer to set up the UI fields with the correct values. Then the
user is back interacting with the validator again until they press Save
again to update the business object.

Really, you could argue that the validator isn't a business layer
object at all... that it's really a UI layer object that knows how to
build and modify business objects. I wouldn't argue with that
interpretation. However, the interaction between the two is still that
the UI chants back and forth with the business layer, asking whether
individual values and relationships between values are OK before trying
to create a real, honest-to-goodness business object, and throughout
the entire process the only exceptions that are thrown occur if the
database update failed, or some other exceptional condition arises.

 

[The Crow]

i realy dont understand you. u seem to create an object just for pickup
values from user for the first time. then you use another object after
record is inserted. this message thread is going to be conservation. maybe
its better to talk in messenger.

 

[Bruce Wood]

No... the user always interacts with the validation object, whether it
is to create a new business object or modify an existing one. The
validation object is, in effect, the UI model. It is responsible for
mediating between the chaotic UI and the orderly world of the business
object.

 

[Jeff Louie]

Bruce... I agree that not all situations require an exception, but argue
that what is exceptional in one situation may be expected in another
situation. This thread did stimulate me to rewrite Chapter 14:

http://www.geocities.com/jeff_louie/OOP/oop14.htm

Regards,
Jeff

 

[Bruce Wood]

you have to deal invalid conditions, whether an exception is thrown, or Validate returns not a null value.

Yes, but exceptions often aren't rich enough to return detailed
information about what went wrong, the kind of information tailored to
what would be meaningful to a user. Exceptions were designed to carry
detailed information about what was going on inside the software when
the failure occurred, which is precisely what is not interesting to the
user, and in many cases precisely the user shouldn't see... see books
on security such as Microsoft's Writing Secure Code:

http://www.amazon.com/exec/obidos/t...bs_b_2_1/002-7096456-3357661?v=glance&s=books

So, you have to catch a particular exception, and then as a programmer
you have a problem: either the exception message is designed for the
user to see, or you have to parse the error message to figure out what
went wrong, or you have to make lots of exception types so that you can
distinguish different errors, or you just give some lame message like,
"Invalid salary." It gets messy because you're using one type of
failure communication-exceptions-to transmit both errors that the
user made in entering data _and_ failures within the system, so at some
level you have to tease those two apart and take appropriate action in
each case. This isn't such a chore in specific routines, such as the
one that tries to translate the annual salary from text into a monetary
value, but becomes tedious (and error-prone) if you just toss a mass of
exceptions up to the UI and say, "Here, UI, you sort this out."

By using two different mechanisms for signalling errors, you make
things clearer, I think: error return values indicate that the user
made a mistake and should be informed; exceptions indicate that the
system is broken, or at least something is failing internally, and they
should be logged for later analysis by programming staff.

And yes, sometimes in the bottom UI layer (or the top business layer,
however you want to think of it), you have to transform exceptions into
error messages, because lower-level routines don't understand the
context and throw exceptions. Even there you can often provide
validation routines that you can call before attempting an operation to
see if it will succeed. Notice that the Framework does this: it
provides, for example TryParse methods so that you can check to see if
a string is a valid representation before actually trying to parse it.
Even if you can't, and have to deal with an exception, you transform it
into a meaningful error messages as soon as you can, so that higher
levels don't have to distinguish between this exception (which is a
message for the user) and other exceptions (which indicate application
failure).

My point, though, when all is said and done, is that the code is
clearer and easier to manage if you avoid bubbling exceptions up to the
UI and forcing it to distinguish between system errors and user
mistakes; it's tidier to have two error vectors: error messages for bad
input, and exceptions for true failures.