Good practice for returning "status" from functions

[roger.dunham]

Hi there,

I am writing an application that performs calculations on records
within a data table. There may be many records in a data table.

There are situations where the calculation may not be able to return a
meaningful value (e.g. Divide by zero) and null (or other default) is
returned instead. This is not a fatal error, so processing can
continue on the rest of the data table. As such, the table may
ultimately end up with a mixture of some correctly calculated and
uncalculated values.

In that situation I would like to be able to warn the user that some
values could not be calculated. Ideally I would like to be able to
tell them the records where this occurred.

I have used C# for a number of years and understand how to use
Exceptions, and Inner Exceptions. However exceptions are not
appropriate here as processing continued.

How do other developers deal with returning information about status?
Do you return a single status code (e.g. -204, which can be translated
into a helpful string such as "division by zero occurred in some
records"), or something more complex? Alternatively, have Microsoft
implemented something in .NET that I have yet to find?

Thanks in anticipation

Roger

[=?Utf-8?B?TW9kZWxCdWlsZGVy?=]

I'm not sure I understand why exceptions are not appropriate for your case.
Your custom return values are just a different packaging mechanism to an
exception. Your receiver code handling the custom return value is just a
different mechanism for handling what normally would be an exception. I
would think your exception handler from the client would be coded similarly
to what your code does for the custom return value, but does so based on the
exception message or a customized exception property.

"ro**********@talk21.com" wrote:

Hi there,

I am writing an application that performs calculations on records
within a data table. There may be many records in a data table.

There are situations where the calculation may not be able to return a
meaningful value (e.g. Divide by zero) and null (or other default) is
returned instead. This is not a fatal error, so processing can
continue on the rest of the data table. As such, the table may
ultimately end up with a mixture of some correctly calculated and
uncalculated values.

In that situation I would like to be able to warn the user that some
values could not be calculated. Ideally I would like to be able to
tell them the records where this occurred.

I have used C# for a number of years and understand how to use
Exceptions, and Inner Exceptions. However exceptions are not
appropriate here as processing continued.

How do other developers deal with returning information about status?
Do you return a single status code (e.g. -204, which can be translated
into a helpful string such as "division by zero occurred in some
records"), or something more complex? Alternatively, have Microsoft
implemented something in .NET that I have yet to find?

Thanks in anticipation

Roger

[roger.dunham]

A fair point

However, throwing an exception will terminate processing as something
"couldn't be done". In this case what the user wanted couldn't be
done, so the default value was used in stead, and then the processing
can continue with the next records.
Hope that helps.

Roger

[AMDRIT]

There are a number of things you can do. First, I agree, Exceptions have a
different purpose and meaning, so you should implement a solution that works
for you.

given the idea signature divide(decimal,decimal) decimal

We know that there are reasons that you cannot perform the division, one is
that you cannot divide by zero. You expect an exception to occur in this
condition, and since you can account for it it will not break stability in
the program.

So you can do a couple things to get informative information.

A tried and true method is similar to the dialog result.

divide( decimal, decimal, decimal) mathresult

the first to inputs are the inputs for the calculation the third is the
outbound result of the computation and mathresult is either an enum of
status messages or an object containing informative information.

My other ideas are really variations upon this.
Say you have a more complex calculations to perform, for me it would be
rating an insurance premium.

function compute(policy as Policy) as PolicyRate
end funciton

Here I must pass in the entire policy, loop over each item with coverage,
then over each coverage or coverage group and compute a rate, then sum up
all the rates for each item with coverage, then sum up for the policy.
Should a calculation fail, or we can determine bad values, we pass back
informative help for the user so they may change their selections.

dim pr as PolicyRate = RatingEngine.Compute(policy)
if not pr.status = Success then
'tell the user of their bobo
dim dlg as new PolicyErrorDialog(pr)
dlg.show(me)
else
'Display the computed rates
dim dlg as new RatingWorksheet(pr)
dlg.show(me)
end if

Certainly, I have exception management in my calculation routines and even a
generic handler. I have decision trees wrapped around the known potential
issues and in the event of something unexpected, I make note of it and stop
the calculation. Flow of the application remains constant.

try
catch (calculationExceptions) 'Based on Logic
'Prevent minor calculations, most likely a bad value or unexpected result
catch (databaseExceptions) 'Based on environment
'Prevent lookups for factors and surcharges, Network group must be at it
again.
catch (Exception) 'Who knows
'stops calculation processing for an unexpected reason
end try

<ro**********@talk21.comwrote in message
news:11**********************@n60g2000hse.googlegr oups.com...

>A fair point

However, throwing an exception will terminate processing as something
"couldn't be done". In this case what the user wanted couldn't be
done, so the default value was used in stead, and then the processing
can continue with the next records.
Hope that helps.

Roger