Exception vs Boolean

[Shehab Kamal]

Which approach is better:
1) Use a method that returns true/false (the method will log the exception
that lead to false using log4net for example)
OR
2) Use a method that returns void and throws an exception in case of failure?

If the second approach is to be suggested: Should .NET predefined
exceptions, NullReferenceEx ception, IndexOutOfRange Exception and so on, or my
own exceptions be thrown?

Thanks in advance,
Shehab.

[Cor Ligthert [MVP]]

Jon,

I note you didn't answer about
having to check a status after calling ArrayList.Add each time...

What exception you want to add to that, it is accepting every type of
object.

Scott nor either me have told that you should add exceptions or a retunr
code to every method, I think that it is understood somewhere from your
text. I agree with you that VB is more clear in this by its seperation of
void methods and non void methods with different names.

Cor

[Phil]

On Mon, 14 Aug 2006 13:31:22 +0200, "Cor Ligthert [MVP]"
<no************ @planet.nlwrote :

>Jon,

I note you didn't answer about
having to check a status after calling ArrayList.Add each time...

What exception you want to add to that, it is accepting every type of
object.

So what? It could throw OutOfMemoryExce ption, or ThreadAbortExce ption,
for example.

The CLR is designed to use exceptions and you would be better to
conform your code to that design paradigm. People using your code will
find it easier too :-)
--
Phil

[Jon Skeet [C# MVP]]

Cor Ligthert [MVP] wrote:

I note you didn't answer about
having to check a status after calling ArrayList.Add each time...

What exception you want to add to that, it is accepting every type of
object.

ArrayList.Add can thrown an exception if the list is read-only or a
fixed size.
If you don't like that example, what about ArrayList.Inser t which takes
an index which must be validated?

Jon

[Scott M.]

What about:

dim x as double = 6 / 0

or

dim y as double = 0 / 0

What exceptions do we get there?

In VB 6.0, these would have resulted in errors (err), but because they are
(unfortunately) attempted so often, NaN and Infinity are what we get back,
rather than exceptions.

So, I don't think it's quite accurate to say that the .NET Framework is
built around exceptions occuring as a reslut of failure.

I also think you are splitting hairs here. My comments were not mean as an
absolute. Discression is always required when a decision has to be made and
my comments were made with that understanding.

If you had read my other post in the thread, as I suggested, you would have
seen my boiled down recommendation:

----------------------------------------------------------------

Silva M wrote:
From the horse mouth:
http://blogs.msdn.com/kcwalina/archi...16/396787.aspx

>Scott M wrote:
I think that article sums it up quite nicely:

>Do not use exceptions for normal execution flow.
Do use exeptions for system failures.

--------------------------------------------------------------------
"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:11******** **************@ h48g2000cwc.goo glegroups.com.. .

Cor Ligthert [MVP] wrote:

> I note you didn't answer about
having to check a status after calling ArrayList.Add each time...

What exception you want to add to that, it is accepting every type of
object.

ArrayList.Add can thrown an exception if the list is read-only or a
fixed size.
If you don't like that example, what about ArrayList.Inser t which takes
an index which must be validated?

Jon

[Scott M.]

Then what is the point of IsNaN or IsNull or IsNothing?

Nothing is black and white Phil. There are *exceptions* (sorry) to every
rule. MS does not build the framework exclusively around the exception
paradigm or we wouldn't have values the Null, Nothing and NaN to check for.
"Phil" <fo*@foo.comwro te in message
news:fl******** *************** *********@4ax.c om...

On Mon, 14 Aug 2006 09:34:31 +0200, "Cor Ligthert [MVP]"
<no************ @planet.nlwrote :

>>Jon,

In my idea is the well written text from Scott, completely clear.

In VB it is easy to tell.
Never use an exception in a Sub because than giving back a Boolean or an
enum is more describing and as Scott wrote less consuming processing time.

Decide in a function if you can give a class with an error code in it.
Although in this case is in my idea throwing an exception more describing.

Translating this to C# gives than the answer on the exact OP question,
you
should never let a Void method throw an exception but use a method that
gives back a boolean (or enum).

Just my thought,

Cor

But if you follow this advice you are back to old-style programming
where you have to check the return code of every function (which of
course, nobody ever does); you increase the size of your program and
slow it down with all the extra error checking code. Conversely if you
don't throw an exception then you never pay this penalty.

As Jon said, if exceptions are being raised so often that it is
becoming a performance problem then it's not a truly exceptional
situation and some redesign is in order (cf Int32.TryParse) .
--
Phil

[Scott M.]

Sorry Greg, I was just adding to your comments for Shehab.
"Cowboy (Gregory A. Beamer)" <No************ @comcast.netNoS pamMwrote in
message news:e1******** ******@TK2MSFTN GP05.phx.gbl...

You = preacher
Me = choir

I forget who stated it (will probably remember as soon as I hit send):
"Never trust user input"!

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************** *************** *************** ****
Think outside the box!
*************** *************** *************** ****
"Scott M." <s-***@nospam.nosp amwrote in message
news:eL******** ******@TK2MSFTN GP03.phx.gbl...

>>2. If you find an exceptional condition, for example you can only accept
1-10 and someone sends in an 11, throw a custom exception

And ALWAYS validate end user input prior to accepting the data and
working with it to avoid the potential problems in the first place.

[Phil]

On Mon, 14 Aug 2006 17:28:37 -0400, "Scott M." <s-***@nospam.nosp am>
wrote:

>What about:

dim x as double = 6 / 0

or

dim y as double = 0 / 0

What exceptions do we get there?

Scott, none, and you wouldn't expect any. You will get +Infinity in
the first case and NaN in the second case. That is because it is in
conformance with the IEEE standard for floating point arithmetic. You
can argue about whether the standard is correct but don't expect me to
join you :-)

>In VB 6.0, these would have resulted in errors (err), but because they are
(unfortunately ) attempted so often, NaN and Infinity are what we get back,
rather than exceptions.

Anybody doing any serious mathematical work has got a lot more to
worry about than whether an exception is going to be thrown by the
code above...a brief hunt around on a few websites indicates this is a
huge and complex topic which fortunately my tired brain does not have
to grasp at the moment.

Regards,

--
Phil

[Jon Skeet [C# MVP]]

Scott M. <s-***@nospam.nosp amwrote:

What about:

dim x as double = 6 / 0

or

dim y as double = 0 / 0

What exceptions do we get there?

Well, with the integer versions of course, we *do* get exceptions.

In VB 6.0, these would have resulted in errors (err), but because they are
(unfortunately) attempted so often, NaN and Infinity are what we get back,
rather than exceptions.

I don't believe it's because they're attempted so often - I believe
it's because the IEEE standard on which .NET floating point is based
defines the results to these operations.

So, I don't think it's quite accurate to say that the .NET Framework is
built around exceptions occuring as a reslut of failure.

I think it largely is - for the most part, if you give an invalid
parameter to a method, it'll throw an appropriate exception rather than
returning a status code of some description. I think if we were to list
examples following the exception rule they would be *vastly* greater
than the list of examples following the status code idea.

I also think you are splitting hairs here. My comments were not mean as an
absolute. Discression is always required when a decision has to be made and
my comments were made with that understanding.

Unfortunately it's my experience that comments aren't always taken with
that borne in mind.

If you had read my other post in the thread, as I suggested, you would have
seen my boiled down recommendation:

I don't think the article backs up your "avoid exceptions when you
can" recommendation *at all*. In particular, it categorically goes
against Cor's interpretation of your post - the very first "bullet
point" states: "Do not return error codes. Exceptions are the primary
means of reporting errors in frameworks." Either Cor's interpretation
of your post was flawed, or your point directly went against the
article. It would be nice if you'd clear up which is the case.
Compare:
"Do report execution failures by throwing exceptions. If a member
cannot successfully do what [it] is designed to do, it should be
considered an execution failure and an exception should be thrown."
and later:
"Do not use error codes because of concerns that exceptions might
affect performance negatively."

with:
"Exceptions are expensive in terms of CLR performance and so, you
should avoid throwing them when you can."

One of the primary ways people avoid throwing exceptions is by using
error codes - I don't think interpreting your post as encouraging the
use of error codes is unreasonable, but it's completely different to
the article.
I personally lean far closer to the article than any interpretation I
can put on your "avoidance" post. They seem worlds apart to me.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Cor Ligthert [MVP]]

Jon,

As I wrote, did I have not any problem with Scott his first reply, maybe I
should have avoided to give any own interpretation of that, while you are
now hashing the replies up with a lot of not to the subject belonging text
about what Scott wrote..

I could not find any point in your replies which made it more clear what you
want, this in opposite to the first reply from Scott, which is a newsgroup
answer, not a proof.

Maybe it would be have better if you did your own reply to Shehab instead of
splitting hairs on Scott his message, as I completely have to agree with
Scott that this is done by you.

By the way, I have more times told you that if you quote me in any way it
should be right, I don't want to be misquoted. I follow completely the line
as what Scott was writing. That you are misquoting that by your own text is
again something that shows that you use that technique.

Scott wrote in his first message the main sentence

>Exceptions are expensive in terms of CLR performance and so, you should

avoid throwing them when you can.

He showed than in the next sentence that trying to avoid them did not mean
never use them and gave an example how that than could be the best done.

That is were my additions are based on. Absolute not on this misquoting by
you where ever he wrote that in another context.

>Do not return error codes. Exceptions are the primary means of reporting
errors in frameworks."

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.co mschreef in bericht
news:MP******** *************** *@msnews.micros oft.com...

Scott M. <s-***@nospam.nosp amwrote:

>What about:

dim x as double = 6 / 0

or

dim y as double = 0 / 0

What exceptions do we get there?

Well, with the integer versions of course, we *do* get exceptions.

>In VB 6.0, these would have resulted in errors (err), but because they
are
(unfortunately ) attempted so often, NaN and Infinity are what we get
back,
rather than exceptions.

I don't believe it's because they're attempted so often - I believe
it's because the IEEE standard on which .NET floating point is based
defines the results to these operations.

>So, I don't think it's quite accurate to say that the .NET Framework is
built around exceptions occuring as a reslut of failure.

I think it largely is - for the most part, if you give an invalid
parameter to a method, it'll throw an appropriate exception rather than
returning a status code of some description. I think if we were to list
examples following the exception rule they would be *vastly* greater
than the list of examples following the status code idea.

>I also think you are splitting hairs here. My comments were not mean as
an
absolute. Discression is always required when a decision has to be made
and
my comments were made with that understanding.

Unfortunately it's my experience that comments aren't always taken with
that borne in mind.

>If you had read my other post in the thread, as I suggested, you would
have
seen my boiled down recommendation:

I don't think the article backs up your "avoid exceptions when you
can" recommendation *at all*. In particular, it categorically goes
against Cor's interpretation of your post - the very first "bullet
point" states: "Do not return error codes. Exceptions are the primary
means of reporting errors in frameworks." Either Cor's interpretation
of your post was flawed, or your point directly went against the
article. It would be nice if you'd clear up which is the case.
Compare:
"Do report execution failures by throwing exceptions. If a member
cannot successfully do what [it] is designed to do, it should be
considered an execution failure and an exception should be thrown."
and later:
"Do not use error codes because of concerns that exceptions might
affect performance negatively."

with:
"Exceptions are expensive in terms of CLR performance and so, you
should avoid throwing them when you can."

One of the primary ways people avoid throwing exceptions is by using
error codes - I don't think interpreting your post as encouraging the
use of error codes is unreasonable, but it's completely different to
the article.
I personally lean far closer to the article than any interpretation I
can put on your "avoidance" post. They seem worlds apart to me.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Cor Ligthert [MVP]]

By the way, if Scott wrote this somewhere,

>Do not return error codes. Exceptions are the primary means of reporting
errors in frameworks."

Than do I agree with that in the context of his first message as well. I was
only talking about Booleans and Enums, in general do I agree with the text
above if it cannot be done in a simple way with returning the first two
types used in my message. I never would advice to use any return code.

And to show that this can be even different, just have a look at the
DataAdapter Update where the returned integer can be used to see if all the
rows are completely updated as it should be, this beside the exceptions also
in this method (which can be set to ignore in the same method).

Cor

"Cor Ligthert [MVP]" <no************ @planet.nlschre ef in bericht
news:O4******** ********@TK2MSF TNGP04.phx.gbl. ..

Jon,

As I wrote, did I have not any problem with Scott his first reply, maybe I
should have avoided to give any own interpretation of that, while you are
now hashing the replies up with a lot of not to the subject belonging text
about what Scott wrote..

I could not find any point in your replies which made it more clear what
you want, this in opposite to the first reply from Scott, which is a
newsgroup answer, not a proof.

Maybe it would be have better if you did your own reply to Shehab instead
of splitting hairs on Scott his message, as I completely have to agree
with Scott that this is done by you.

By the way, I have more times told you that if you quote me in any way it
should be right, I don't want to be misquoted. I follow completely the
line as what Scott was writing. That you are misquoting that by your own
text is again something that shows that you use that technique.

Scott wrote in his first message the main sentence

>>Exceptions are expensive in terms of CLR performance and so, you should

avoid throwing them when you can.

He showed than in the next sentence that trying to avoid them did not mean
never use them and gave an example how that than could be the best done.

That is were my additions are based on. Absolute not on this misquoting by
you where ever he wrote that in another context.

>>Do not return error codes. Exceptions are the primary means of reporting
errors in frameworks."

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.co mschreef in bericht
news:MP******** *************** *@msnews.micros oft.com...

>Scott M. <s-***@nospam.nosp amwrote:

>>What about:

dim x as double = 6 / 0

or

dim y as double = 0 / 0

What exceptions do we get there?

Well, with the integer versions of course, we *do* get exceptions.

>>In VB 6.0, these would have resulted in errors (err), but because they
are
(unfortunatel y) attempted so often, NaN and Infinity are what we get
back,
rather than exceptions.

I don't believe it's because they're attempted so often - I believe
it's because the IEEE standard on which .NET floating point is based
defines the results to these operations.

>>So, I don't think it's quite accurate to say that the .NET Framework is
built around exceptions occuring as a reslut of failure.

I think it largely is - for the most part, if you give an invalid
parameter to a method, it'll throw an appropriate exception rather than
returning a status code of some description. I think if we were to list
examples following the exception rule they would be *vastly* greater
than the list of examples following the status code idea.

>>I also think you are splitting hairs here. My comments were not mean as
an
absolute. Discression is always required when a decision has to be made
and
my comments were made with that understanding.

Unfortunatel y it's my experience that comments aren't always taken with
that borne in mind.

>>If you had read my other post in the thread, as I suggested, you would
have
seen my boiled down recommendation:

I don't think the article backs up your "avoid exceptions when you
can" recommendation *at all*. In particular, it categorically goes
against Cor's interpretation of your post - the very first "bullet
point" states: "Do not return error codes. Exceptions are the primary
means of reporting errors in frameworks." Either Cor's interpretation
of your post was flawed, or your point directly went against the
article. It would be nice if you'd clear up which is the case.
Compare:
"Do report execution failures by throwing exceptions. If a member
cannot successfully do what [it] is designed to do, it should be
considered an execution failure and an exception should be thrown."
and later:
"Do not use error codes because of concerns that exceptions might
affect performance negatively."

with:
"Exceptions are expensive in terms of CLR performance and so, you
should avoid throwing them when you can."

One of the primary ways people avoid throwing exceptions is by using
error codes - I don't think interpreting your post as encouraging the
use of error codes is unreasonable, but it's completely different to
the article.
I personally lean far closer to the article than any interpretation I
can put on your "avoidance" post. They seem worlds apart to me.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too