473,372 Members | 898 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,372 software developers and data experts.

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
Jul 21 '05 #1
11 2814
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

Jul 21 '05 #2
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.


Jul 21 '05 #3

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

Jul 21 '05 #4
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


Jul 21 '05 #5
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

Jul 21 '05 #6
>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
Jul 21 '05 #7
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

Jul 21 '05 #8
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.


Jul 21 '05 #9
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
Jul 21 '05 #10
>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
Jul 21 '05 #11
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

Jul 21 '05 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
by: StepH | last post by:
Hi, I've this module : from optparse import OptionParser import re _version = "P1" def writeVar(f, line):
12
by: Eric Lilja | last post by:
Hello, I'm working with a hash table that is encapsulated in a class. One of its member functions insert() throws an exception if the insertion fails (for example, if the value was already present...
5
by: n_o_s_p_a__m | last post by:
Can't compile. Does this mean that all functions that throw exceptions must be of return type void? examples: // won't compile: "not all code paths return a value" public override int Run() {...
8
by: Daniel Billingsley | last post by:
Suppose I have a method that returns some type of object, and in that method I have a try...catch block and just throw my own exception when I catch one. The compiler insists that all code paths...
44
by: craig | last post by:
I am wondering if there are some best practices for determining a strategy for using try/catch blocks within an application. My current thoughts are: 1. The code the initiates any high-level...
40
by: Kevin Yu | last post by:
is it a bad programming design to throw exception in the try block then catch it??
6
by: Steve Long | last post by:
Help, I'm running VS.NET 2003 and when I try to start my application, I get the "unhandled exception" dialog instead of the IDE highlighting the offending line of code. The problem appears to be...
9
by: MR | last post by:
I get the following Exception "The data at the root level is invalid. Line 1, position 642" whenever I try to deserialize an incoming SOAP message. The incoming message is formed well and its...
1
by: metsys | last post by:
We have an ASP.NET 2.0 (C#) application that is divided into multiple layers. The multiple layers come from having a web project and 2 different class library projects in the same solution. I'm...
7
by: Yarco | last post by:
Well, friend. Yes, I'm doing PHP. But exception is a traditional machinism in programming languages. I'm very doubt about this. In procedure language, we return error code when we meet an error. So...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...
0
by: ryjfgjl | last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.