Exception vs Return Code

  • Thread starter Thread starter adi
  • Start date Start date
A

adi

Dear all,

This is more like a theoretical or conceptual question:
which is better, using exception or return code for
a .NET component?

I had created a COM object (using VB6), which uses return
code (not generating error/exception) so it is more
compatible with other programming language.

Now we are migrating the COM object into .NET component
but wondering whether I should change my code to work
with exception instead? How popular is the use of
exception? Is it supported by all .NET-enabled
programming language?

Thanks,
Adi
 
Exceptions are the way to go. Yes, they are supported across all the .NET
languages because all the languages support the same class libraries and the
Exception class is in there.

You can create your own custom exceptions as well and then give them their
own description (message) as well as source.

By using exceptions, you gain the ability to use structured exception
handling (Try...Catch...Finally), which is the preferred way.
 
Hi Scott,

Thank you for your answer. I guess the next question
would be: why is the exception preferred than result
code? Is there any technical reasons behind it? Or is it
just something new or trendy.

What I found out so far is most non-Microsoft language
may not be compatible with exception handling. I guess
it's old fashion to use return error code, but it seems
to be widely accepted and easier to understood (or maybe
used to it).

I will have to justify the time required to replace the
return code with exception class. So, a good
technical/business perception would be greatly
appreciated.

Regards,
Adi
 
[email protected] said:
Hi Scott,

Thank you for your answer. I guess the next question
would be: why is the exception preferred than result
code? Is there any technical reasons behind it? Or is it
just something new or trendy.
Click to expand...

Not new by any means, just new to VB. Java, JavaScript, C & C++ have used
Structured Exception Handling for some time.

The idea of "Structured Exception Handling" is, well more structured than
the awkward VB "On Error GoTo" or "On Error Resume Next" way.

It looks like this....

Try
'Code that could fail goes here
Catch n as ExceptionType
'Code that should run when the ExceptionType mentioned above is raised
'The name you give to the exception, "n" in this case is used to
represent the exception and
'can therefore be interrogated with standard exception properties
'such as "Message" (like the old VB Description) and Source (which
indicates what assembly threw the exception
Catch n1 as OtherExceptionType
'Ditto the above
Catch n99 as Exception
'Note that the last "Catch" you test for should test for just a plain
"Exception" and not
'any specific type of exception
'This serves as a "Catch All" for any exceptions you didn't specifically
test for
Finally
'This section is not required but any code in here
'will run whether there is an exception or not
End Try

You can see that there is much more "Structure" to the process using this
method and because many other languages already used this way, it's a
consistent approach to error handling.

If you caught errors only by codes returned, you wouldn't be able to use
this method beause, by definition, Structured Exception Handling handles
exception "types" not error codes.
What I found out so far is most non-Microsoft language
may not be compatible with exception handling. I guess
it's old fashion to use return error code, but it seems
to be widely accepted and easier to understood (or maybe
used to it).
Click to expand...

Not true, see my first line of comments.
I will have to justify the time required to replace the
return code with exception class. So, a good
technical/business perception would be greatly
appreciated.
Click to expand...

Much more consitent with other languages (Java, JavaScript, C, C++, C# and
more)
More powerfull when working in an OO language (Exceptions are classes and
therefore creating custom exceptions is as simple as creating a new class
that inherits from the base exception class).

Hope this helps!

-Scott
 
Thank you Scott. Exactly what I needed.
Will have to spend time on planning for this change then.

Adi
 
This is more like a theoretical or conceptual question:
which is better, using exception or return code for
a .NET component?
Click to expand...

I'd use exceptions - I find it a lot easier to be able to write

try
{
// do step 1
// do step 2
.......
// do step n
}
catch(Exception1 ex1)
{
// handle it
}
catch(Exception2 ex2)
{
// handle it
}

instead of having to explicitly check for a return value for each
call. Also - an exception is an object and thus you can stash a lot
more information into it, e.g. you don't have to "implicitly" know
what error -3475623847 means - you can spell it out in plain text!

Marc
 
I'll step in here, however, and make a few quick comments. Exceptions are
expensive operations and should really only be used in exceptional
situations, generally in errors, not failures. Don't be afraid to use a
boolean return value in cases where failure can occur fairly commonly, or to
return null if an object lookup failed.
For example, if you have an error code that specifiys no records were
returned from a query, that method should either return null or an empty
record collection(preferable), not throw an exception. Using an exception
here would start to use exceptions to control program flow, which is ill
advised, imho, as well as kill performance considering an query is never
guarenteed to result in a record.
On the other hand, if you recieve an ill formed query or a incorrect record
format, null argument, etc, an exception is ideal.
 
In addition to all the benefits other people have pointed out there is another.

One of the most common problems in programs is not checking return codes.
Programmers often ignore return codes because handling errors is a pain so
errors go undetected and cause the programs to crash in strange ways.
The exception model reverses the problem, by default all exceptions are fatal
and are handled by causing the program to terminate so there is no chance of
missing an error because you forgot to check for it. Instead you only have to
deal with the error if it is something you need to deal with.

It's a different more robust model that says errors should not be silent by
default.

-- Kevin
 
Back
Top