Exception vs Return Code

**Scott M.** · Jul 21 '05, 10:51 AM

Re: Exception vs Return Code

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@message4u. com" <anonymous@disc ussions.microso ft.com> wrote in message
news:01f701c3b5 49$a63691a0$a50 1280a@phx.gbl.. .[color=blue]
> 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[/color]

**adi@message4u.com** · Jul 21 '05, 10:51 AM

Re: Exception vs Return Code

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
[color=blue]
>-----Original Message-----
>Exceptions are the way to go. Yes, they are supported[/color]
across all the .NET[color=blue]
>languages because all the languages support the same[/color]
class libraries and the[color=blue]
>Exception class is in there.
>
>You can create your own custom exceptions as well and[/color]
then give them their[color=blue]
>own description (message) as well as source.
>
>By using exceptions, you gain the ability to use[/color]
structured exception[color=blue]
>handling (Try...Catch... Finally), which is the preferred[/color]
way.[color=blue]
>[/color]

**Scott M.** · Jul 21 '05, 10:51 AM

Re: Exception vs Return Code

"adi@message4u. com" <anonymous@disc ussions.microso ft.com> wrote in message
news:026301c3b5 53$8342ec20$a50 1280a@phx.gbl.. .[color=blue]
> 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.[/color]

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 OtherExceptionT ype
'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.
[color=blue]
>
> 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).[/color]

Not true, see my first line of comments.
[color=blue]
>
> 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.[/color]

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
[color=blue]
>
> Regards,
> Adi
>[color=green]
> >-----Original Message-----
> >Exceptions are the way to go. Yes, they are supported[/color]
> across all the .NET[color=green]
> >languages because all the languages support the same[/color]
> class libraries and the[color=green]
> >Exception class is in there.
> >
> >You can create your own custom exceptions as well and[/color]
> then give them their[color=green]
> >own description (message) as well as source.
> >
> >By using exceptions, you gain the ability to use[/color]
> structured exception[color=green]
> >handling (Try...Catch... Finally), which is the preferred[/color]
> way.[color=green]
> >[/color]
>[/color]

**adi@message4u.com** · Jul 21 '05, 10:51 AM

Re: Exception vs Return Code

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

Adi
[color=blue]
>-----Original Message-----
>
>"adi@message4u .com"[/color]
<anonymous@disc ussions.microso ft.com> wrote in message[color=blue]
>news:026301c3b 553$8342ec20$a5 01280a@phx.gbl. ..[color=green]
>> 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[/color][/color]
it[color=blue][color=green]
>> just something new or trendy.[/color]
>
>Not new by any means, just new to VB. Java, JavaScript,[/color]
C & C++ have used[color=blue]
>Structured Exception Handling for some time.
>
>The idea of "Structured Exception Handling" is, well[/color]
more structured than[color=blue]
>the awkward VB "On Error GoTo" or "On Error Resume Next"[/color]
way.[color=blue]
>
>It looks like this....
>
>Try
> 'Code that could fail goes here
>Catch n as ExceptionType
> 'Code that should run when the ExceptionType[/color]
mentioned above is raised[color=blue]
> 'The name you give to the exception, "n" in this[/color]
case is used to[color=blue]
>represent the exception and
> 'can therefore be interrogated with standard[/color]
exception properties[color=blue]
> 'such as "Message" (like the old VB Description) and[/color]
Source (which[color=blue]
>indicates what assembly threw the exception
>Catch n1 as OtherExceptionT ype
> 'Ditto the above
>Catch n99 as Exception
> 'Note that the last "Catch" you test for should test[/color]
for just a plain[color=blue]
>"Exception" and not
> 'any specific type of exception
> 'This serves as a "Catch All" for any exceptions you[/color]
didn't specifically[color=blue]
>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[/color]
process using this[color=blue]
>method and because many other languages already used[/color]
this way, it's a[color=blue]
>consistent approach to error handling.
>
>If you caught errors only by codes returned, you[/color]
wouldn't be able to use[color=blue]
>this method beause, by definition, Structured Exception[/color]
Handling handles[color=blue]
>exception "types" not error codes.
>[color=green]
>>
>> 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[/color][/color]
maybe[color=blue][color=green]
>> used to it).[/color]
>
>Not true, see my first line of comments.
>[color=green]
>>
>> 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.[/color]
>
>Much more consitent with other languages (Java,[/color]
JavaScript, C, C++, C# and[color=blue]
>more)
>More powerfull when working in an OO language[/color]
(Exceptions are classes and[color=blue]
>therefore creating custom exceptions is as simple as[/color]
creating a new class[color=blue]
>that inherits from the base exception class).
>
>Hope this helps!
>
>-Scott[/color]

**Scott M.** · Jul 21 '05, 10:51 AM

Re: Exception vs Return Code

HTH :)

"adi@message4u. com" <anonymous@disc ussions.microso ft.com> wrote in message
news:036e01c3b5 57$d92ea1c0$a40 1280a@phx.gbl.. .[color=blue]
> Thank you Scott. Exactly what I needed.
> Will have to spend time on planning for this change then.
>
> Adi
>[color=green]
> >-----Original Message-----
> >
> >"adi@message4u .com"[/color]
> <anonymous@disc ussions.microso ft.com> wrote in message[color=green]
> >news:026301c3b 553$8342ec20$a5 01280a@phx.gbl. ..[color=darkred]
> >> 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[/color][/color]
> it[color=green][color=darkred]
> >> just something new or trendy.[/color]
> >
> >Not new by any means, just new to VB. Java, JavaScript,[/color]
> C & C++ have used[color=green]
> >Structured Exception Handling for some time.
> >
> >The idea of "Structured Exception Handling" is, well[/color]
> more structured than[color=green]
> >the awkward VB "On Error GoTo" or "On Error Resume Next"[/color]
> way.[color=green]
> >
> >It looks like this....
> >
> >Try
> > 'Code that could fail goes here
> >Catch n as ExceptionType
> > 'Code that should run when the ExceptionType[/color]
> mentioned above is raised[color=green]
> > 'The name you give to the exception, "n" in this[/color]
> case is used to[color=green]
> >represent the exception and
> > 'can therefore be interrogated with standard[/color]
> exception properties[color=green]
> > 'such as "Message" (like the old VB Description) and[/color]
> Source (which[color=green]
> >indicates what assembly threw the exception
> >Catch n1 as OtherExceptionT ype
> > 'Ditto the above
> >Catch n99 as Exception
> > 'Note that the last "Catch" you test for should test[/color]
> for just a plain[color=green]
> >"Exception" and not
> > 'any specific type of exception
> > 'This serves as a "Catch All" for any exceptions you[/color]
> didn't specifically[color=green]
> >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[/color]
> process using this[color=green]
> >method and because many other languages already used[/color]
> this way, it's a[color=green]
> >consistent approach to error handling.
> >
> >If you caught errors only by codes returned, you[/color]
> wouldn't be able to use[color=green]
> >this method beause, by definition, Structured Exception[/color]
> Handling handles[color=green]
> >exception "types" not error codes.
> >[color=darkred]
> >>
> >> 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[/color][/color]
> maybe[color=green][color=darkred]
> >> used to it).[/color]
> >
> >Not true, see my first line of comments.
> >[color=darkred]
> >>
> >> 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.[/color]
> >
> >Much more consitent with other languages (Java,[/color]
> JavaScript, C, C++, C# and[color=green]
> >more)
> >More powerfull when working in an OO language[/color]
> (Exceptions are classes and[color=green]
> >therefore creating custom exceptions is as simple as[/color]
> creating a new class[color=green]
> >that inherits from the base exception class).
> >
> >Hope this helps!
> >
> >-Scott[/color]
>[/color]

**Marc Scheuner [MVP ADSI]** · Jul 21 '05, 10:51 AM

Re: Exception vs Return Code

>This is more like a theoretical or conceptual question:[color=blue]
>which is better, using exception or return code for
>a .NET component?[/color]

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(Exception 1 ex1)
{
// handle it
}
catch(Exception 2 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** · Jul 21 '05, 10:51 AM

Re: Exception vs Return Code

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(pref erable), 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.scheuner@ino va.SPAMBEGONE.c h> wrote in message
news:kdsdsvsj69 mamid1ufh32t83v m5g960rtb@4ax.c om...[color=blue][color=green]
> >This is more like a theoretical or conceptual question:
> >which is better, using exception or return code for
> >a .NET component?[/color]
>
> 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(Exception 1 ex1)
> {
> // handle it
> }
> catch(Exception 2 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[/color]

**adi@message4u.com** · Jul 21 '05, 10:53 AM

Re: Exception vs Return Code

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

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

**adi@message4u.com** · Jul 21 '05, 10:53 AM

Exception vs Return Code

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]** · Jul 21 '05, 10:53 AM

Re: Exception vs Return Code

>I'll step in here, however, and make a few quick comments. Exceptions are[color=blue]
>expensive operations and should really only be used in exceptional
>situations, generally in errors, not failures.[/color]

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

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)i nova.ch

**Kevin Gale** · Jul 21 '05, 10:54 AM

Re: Exception vs Return Code

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

"adi@message4u. com" <anonymous@disc ussions.microso ft.com> wrote in message
news:01f701c3b5 49$a63691a0$a50 1280a@phx.gbl.. .[color=blue]
> 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[/color]

Exception vs Return Code

Exception vs Return Code

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment