Exception vs Return Code

[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

[Scott M.]

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.
"ad*@message4u.com" <an*******@discussions.microsoft.com> wrote in message
news:01****************************@phx.gbl...

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

[adi]

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

-----Original Message-----
Exceptions are the way to go. Yes, they are supported across all the .NETlanguages because all the languages support the same class libraries and theException class is in there.

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

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

[Scott M.]

"ad*@message4u.com" <an*******@discussions.microsoft.com> wrote in message
news:02****************************@phx.gbl...

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.
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).
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.
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

Regards,
Adi

-----Original Message-----
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.

[adi]

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

Adi

-----Original Message-----

"ad*@message4u.com" <an*******@discussions.microsoft.com> wrote in messagenews:02****************************@phx.gbl...

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.
Not new by any means, just new to VB. Java, JavaScript,

C & C++ have usedStructured Exception Handling for some time.

The idea of "Structured Exception Handling" is, well more structured thanthe 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 torepresent the exception and
'can therefore be interrogated with standard exception properties 'such as "Message" (like the old VB Description) and Source (whichindicates 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 specificallytest 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 thismethod and because many other languages already used this way, it's aconsistent approach to error handling.

If you caught errors only by codes returned, you wouldn't be able to usethis method beause, by definition, Structured Exception Handling handlesexception "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).
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.

Much more consitent with other languages (Java,

JavaScript, C, C++, C# andmore)
More powerfull when working in an OO language (Exceptions are classes andtherefore creating custom exceptions is as simple as creating a new classthat inherits from the base exception class).

Hope this helps!

-Scott

[Scott M.]

HTH :)
"ad*@message4u.com" <an*******@discussions.microsoft.com> wrote in message
news:03****************************@phx.gbl...

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

Adi

-----Original Message-----

"ad*@message4u.com"

<an*******@discussions.microsoft.com> wrote in message

news:02****************************@phx.gbl...

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.

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).

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.

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

[Marc Scheuner [MVP ADSI]]

>This is more like a theoretical or conceptual question:

which is better, using exception or return code for
a .NET component?

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

[Daniel O'Connell]

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.

"Marc Scheuner [MVP ADSI]" <m.********@inova.SPAMBEGONE.ch> wrote in message
news:kd********************************@4ax.com...

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

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

[adi]

Hi Daniel,

You pointed out an interesting point here. The returned
code from my .NET Component methods are generally two
different cases: a real error/exception and a return
value (in case of no records, etc). I used ranges of
numbers to differentiate them (as in HTTP protocol):
1000-1999 = error inside the component (mostly 'soft'
error, not providing a property value, etc)
2000-2999 = error after talking to a server (invalid user
name and/or password, not enough credits, etc)
3000-3999 = error from local components (database error,
etc)

I guess exception is still the way to go here. But I will
keep in mind some of real 'return value' that should stay
on.

Thanks,
Adi

-----Original Message-----
I'll step in here, however, and make a few quick comments. Exceptions areexpensive operations and should really only be used in exceptionalsituations, generally in errors, not failures. Don't be afraid to use aboolean return value in cases where failure can occur fairly commonly, or toreturn null if an object lookup failed.
For example, if you have an error code that specifiys no records werereturned from a query, that method should either return null or an emptyrecord collection(preferable), not throw an exception. Using an exceptionhere would start to use exceptions to control program flow, which is illadvised, imho, as well as kill performance considering an query is neverguarenteed to result in a record.
On the other hand, if you recieve an ill formed query or a incorrect recordformat, null argument, etc, an exception is ideal.

[adi]

Dear all,

Most of my earlier issues with exception are already
answering. But there is still one issue bugging me,
ASP.NET compatibility.

Can anyone explain how ASP.NET works with the new .NET
exception?

Thanks,
Adi

[Marc Scheuner [MVP ADSI]]

>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.
Yes, obviously - that's why they're called "exceptions", right? ;-)
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.

Absolutely. If a lookup fails, or an ID has no clear text associated
with it etc., I wouldn't go around throwing exceptions. But in case
sometimes really bad happens, e.g. a file is locked, or a device can't
be accessed etc., then exceptions are the way to go.

Marc
================================================== ==============
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch

[Kevin Gale]

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
"ad*@message4u.com" <an*******@discussions.microsoft.com> wrote in message
news:01****************************@phx.gbl...

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