I am torn as to the basic approach for tying together VB MTS components and ASP pages. I am creating a hard core Windows DNA application partially as an excercise, but it will be a real web app. I am using SQL 7 and stored procedures, a VB data access component, a VB business componenet and ASP. I am trying to figure out if it's best to handle everything except successful completion of a method as an error, or to use a return integer value indicating various statuses.

As an example: I need to be able to add users. In the database each user gets an ID (identity field), and has an email address (with a unique constraint) plus other info.

I have a stored procedure that checks whether the email already exists, and if not, adds the new users. At the moment, I use the RETURN_VALUE of the stored procedure to indicate that a duplicate email was found by setting it to -1, otherwise it is 0.

In the components, at the moment, my addUser method returns the new ID for the new user, or raises an error if the email is a duplicate (or another error occurs). I am considering changing it to return a status value (i.e. 0 for success, 1 for duplicate email, -1 for unexpected error), and only raising an error for an unexpected error, not for a duplicate email. I would then have to return the new ID value with a parameter passed by reference.

Which approach do you all think is better? As I see it there are the following issues:

Err.Raise advantages:
1. Return values don't need to be passed as variant parameters by reference. This should (I think) make things a bit faster, especially if I am going across machines.

2. The inline code can just assume success. If there is a problem, the error handler will be called.

3. MAYBE slightly easier dealing with MTS transactions by avoiding having to call SetAbort in inline code, and doing it only in the error handling code.

Returning status values advantages:
1. Dealing with unsuccessful method results that are NOT unexpected (i.e. duplicate email address) is easier to handle with inline code. Just check the return value after the call.

2. Simpler error handling routines. The error handling only has to deal with unexpected errors. This is probably more of an issue in VB components using an error handler than in ASP using On Error Resume Next. But looking forward to ASP+ and it's structured error handling, this may become more of an issue.

3. I could return an enumerated type to make the code a little easier to understand.

4. Easier maintainance?? By handling expected problems in regular code, it's clearer later on what is going on(??)

That's the way I see it. Right now I am trying the err.raise approach, but I'm not sure I'm happy with it. Let me know what you think.

Jim Munn

P.S.
Any idea if there is much of a speed penalty marshalling a declared, but uncreated recordset as a by ref parameter? i.e.

dim oRS as ADODB.Recordset
dim oComponent as my.component

' GetUser sets oRS to a disconnected recordset
oComponent.GetUser(strConn, UserID, oRS)

Would this be any faster?

dim oRS as ADODB.Recordset
dim oComponent as my.component

' GetUser returns a disconnected recordset
set oRS = oComponent.GetUser(strConn, UserID)