That's exactly what exceptions are for!
Back in the day, people used return codes and had to know what each possible
return value meant. That could be a PITA when there were dozens of possible
errors and the function would return an integer error code, which you then
had to look up. It frequently resulted in code that looked like this:
int rc = 0;
rc = doSomething();
if (rc == 1) {
//handle some error here
}
else if (rc == 2) {
//handle a different error here
}
else if (rc == 3) {
//handle yet another different error here
}
else if (rc == etc) {
//handle yet another different error here
}
Try/Catch and Exceptions provide a way of raising the error _and_ providing
detail about it at the same time. Now you can write fairly elegant code:
try {
doSomething();
}
catch ex As Exception {
System.out.WriteLine("The error that occurred was " + ex.Message);
}
IMO, exception handling is generally easier to use in that it makes it
easier to deal with error conditions, it's a lot more flexible, and it's
generally easier to follow.
Roland
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Barry Beattie
Sent: Thursday, March 31, 2005 7:19 PM
To: [email protected]
Subject: [CFCDev] exceptions and passing context specific error messages to
the UI
this is (sort of) related to a previous thread (Method Question (was
RE: [CFCDev] OO Security?)
http://www.mail-archive.com/[email protected]/msg08384.html
during a method's running it may (deliberatly) fail in multiple
places. These are mostly foreign-key-constraint-type breaking of
business rules (ie in code but not necessarily set in the db).
a case in point is a delete entity method that has about 3 areas that
it could fail on. The trouble I'm having is sending context-specific
messages back to the user.
preaviously we've been returning "false" if an insert/update/delete
failed but now the UI needs to knowwhy so it can reset and allow the
user to have another go.
some ideas being kicked around:
1) changing the return type from BOOLEAN to STRUCT and returning
result.bOK = false
result.msg = "unique ID already exists"
- or -
2) keep the BOOLEAN (false) value but throw an error to a specific
error object. Break encapsulation by sending the context error message
to the error object to then dump in REQUEST scope. If the UI gets back
FALSE then it checks REQUEST scope for the error and works out what it
needs to do with it (eg: display message + repopulate the form)
I don't like either idea. the BOOLEAN was working just fine but it
just isn't specific enough for different messages to be sent back to
the UI.
any thoughts?
thanx
barry.b
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
