Exception vs Boolean

[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]

Jon,

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

So what? It could throw OutOfMemoryException, or ThreadAbortException,
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

 

[Jon Skeet [C# MVP]]

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.Insert 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/archive/2005/03/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.

 

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

 

[Scott M.]

Sorry Greg, I was just adding to your comments for Shehab.

 

[Jon Skeet [C# MVP]]

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.

 

[Phil]

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,

 

[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

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.

 

[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

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

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.

 

[Scott M.]

I'm not trying to rebuke the IEEE standard at all. If anything, it helps my
point.

I think you and John are trying to somehow paint my comments into a corner
that they were never in. I did not say (despite John's hair-splitting
interpretation) that you should not throw exceptions. My point was that
they should not just haphazardly be used. I went on to say that my feeling
is that exceptions should not be used for flow control purposes, but should
be used for system failures. But (as I also said), nothing is ever
absolute.

The great thing about the framework is that we have the choice to do
whichever suits our needs best. Everything else is a guideline.

I really don't feel that anything else need be said on this by me. I have
found that John consitently feels the need to split hairs in many threads
and beat a dead horse when everyone else seems to understand the point
without disecting the message, word by word.

 

[Jon Skeet [C# MVP]]

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'm comparing what Scott wrote with an article which he referred to as
summing it up quite nicely.

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.

Well, I was interested in some kind of clarification. Scott appears to
be inconsistent, as in one post he appears to agree with the article
and in another he says something contrary.

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.

I've referred to my page on exceptions more than once. It contains a
reasonable amount about when I think it's appropriate to use exceptions
and when it's not.

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.

Yes, you've said that many times. You've often claimed I've misquoted
you, and then avoided replying when I've asked you for evidence.

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.

I don't see how comparing an article Scott claims to agree with, with
his own text, is misquoting.

Scott wrote in his first message the main sentence
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.

Well, I thought that his second sentence was more along the lines of
"If you're going to ignore my advice then..." After all, as I've said,
you virtually never *have* to thrown an exception - you almost always
*can* avoid throwing them.

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

I never claimed he wrote that - merely that he appears (in one post) to
support an article including that as a bullet point.

See http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx
for more - it's a good article.

 

[Jon Skeet [C# MVP]]

By the way, if Scott wrote this somewhere,

No, he didn't.

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.

What? An enum or boolean to indicate success or failure *is* a "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).

Something returning the number of rows updated is *not* the same as an
error code.

 

[Jon Skeet [C# MVP]]

I'm not trying to rebuke the IEEE standard at all. If anything, it helps my
point.

I think you and John are trying to somehow paint my comments into a corner
that they were never in. I did not say (despite John's hair-splitting
interpretation) that you should not throw exceptions. My point was that
they should not just haphazardly be used. I went on to say that my feeling
is that exceptions should not be used for flow control purposes, but should
be used for system failures. But (as I also said), nothing is ever
absolute.

The great thing about the framework is that we have the choice to do
whichever suits our needs best. Everything else is a guideline.

I really don't feel that anything else need be said on this by me. I have
found that John consitently feels the need to split hairs in many threads
and beat a dead horse when everyone else seems to understand the point
without disecting the message, word by word.

I like precision. I've found that if you're imprecise about things,
people get the wrong impression.

Just as an example of that, Cor *appears* to believe that your post
saying to avoid throwing exceptions "when you can" (not "haphazardly" -
there's a marked difference between those two stances, IMO) means that
you should: "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."

Let me ask you straight: do you believe you should never use an
exception in a Sub?

If not, then clearly not everyone *did* understand your post - at least
when it was made.

Personally I'm still unclear exactly where you are in terms of
exceptions, partly because you haven't defined "system failure". The
article pretty much describes it as when a method can't do what it's
designed to do - but you haven't told us what *you* mean by it. (I
wouldn't have chosen the words "system failure" myself because there's
a nuance of failure of the whole computer (system), not just that
machine.)

Your "avoid" post suggests a stance which is primarily one of shying
away from exceptions. This is very different from the article's point
of view. I can't tell whether we actually disagree on when exceptions
should be used, or whether you just weren't expressing yourself well in
the first post. This isn't just splitting hairs - I really don't know
where you stand.

 

[Scott M.]

Hold on John, you can't have it both ways....

Below, you say that an enum or boolean to indicate success or failure *is* a
"return code", but then you say that "Something returning the number of rows
updated is *not* the same as an error code."

When a command object's executeNonQuery method returns zero, isn't that
*possibly* an indication of an error processing the INSERT, UPDATE or
DELETE?

When a DataReader.Read returns False, *couldn't* that be an indication of an
error?

The answer to both of these is absolutely, yes.

 

[Scott M.]

Just as an example of that, Cor *appears* to believe that your post

saying to avoid throwing exceptions "when you can" (not "haphazardly" -
there's a marked difference between those two stances, IMO) means that
you should: "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."

I have not been posting in response to Cor's messages, so I won't comment on
what he wrote.

Let me ask you straight: do you believe you should never use an
exception in a Sub?

No. I have not said absolutely to use, nor have I said explicitly not use
exceptions and that is the crux of your misunderstanding of my position.

If not, then clearly not everyone *did* understand your post - at least
when it was made.

Well, I don't know that you can speak for everyone. In fact, I never
commented on the use of exceptions specifically in Subs at all, so are you
sure *you* understood my post?

Personally I'm still unclear exactly where you are in terms of
exceptions, partly because you haven't defined "system failure". The
article pretty much describes it as when a method can't do what it's
designed to do - but you haven't told us what *you* mean by it. (I
wouldn't have chosen the words "system failure" myself because there's
a nuance of failure of the whole computer (system), not just that
machine.)

Well, for a guy that likes precision, you seem to have a problem here. You
wrote to Cor:

"See http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx
for more - it's a good article."

Which tells me you understood and agree with it. I said that I agree with
it as well. What's the problem?

Your "avoid" post suggests a stance which is primarily one of shying
away from exceptions. This is very different from the article's point
of view. I can't tell whether we actually disagree on when exceptions
should be used, or whether you just weren't expressing yourself well in
the first post. This isn't just splitting hairs - I really don't know
where you stand.

You see those green check marks in the article you mention? You see the red
X's? I interpre the green check marks to mean Yes and the red X's to mean
No. I quoted that article myself and summed it up by using the same
terminology in the article (system failure). In fact, I took my comments
directly from the article. Did you even see that post? Interestgly, on
the one hand, you say it's a good article and then on the other you say you
wouldn't use the terminolgy used in the article. Who's being ambiguous now?

This whole thing boils down to my mistake (not knowing you would read my
post) by ending my sentence with "when you can." How about this John,

"Exceptions are expensive in terms of CLR performance and so, you should
avoid throwing them arbitrarily."

Give it a rest John, you seem to be the only one hung up on verbiage.
You'll live longer without the stress you put on yourself.

PS - Have you considered a career in law? You'd be great for all that
laywer-speak.

 

[Jon Skeet [C# MVP]]

Hold on John, you can't have it both ways....

Below, you say that an enum or boolean to indicate success or failure *is* a
"return code", but then you say that "Something returning the number of rows
updated is *not* the same as an error code."

When a command object's executeNonQuery method returns zero, isn't that
*possibly* an indication of an error processing the INSERT, UPDATE or
DELETE?

Yes, but it's more than that. It's a useful indicator even for success
cases.

When a DataReader.Read returns False, *couldn't* that be an indication of an
error?

Not at reading a record. It may indicate that you got your query wrong,
but not that the method failed.

The answer to both of these is absolutely, yes.

In neither of these cases has the code failed to do what it was
designed to do. It may not have had the effect that the developer
calling it intended, but that's a different matter.

I agree that there are corner cases, however - things like
String.IndexOf returning -1 isn't really an "error" but it's indicating
a "string not found" condition using the same mechanism that the
position of the "string found" condition.

I don't object too much to that, so long as it's not overused. It would
be a different matter if it started returning different numbers for
different error statuses.

 

[Jon Skeet [C# MVP]]

I have not been posting in response to Cor's messages, so I won't comment on
what he wrote.

But don't you see that his response backs up my claim that your post
was ambiguous?

No. I have not said absolutely to use, nor have I said explicitly not use
exceptions and that is the crux of your misunderstanding of my position.

I think you're the one splitting hairs now, between saying to avoid
throwing exceptions and not explicitly saying not to use them.

Well, I don't know that you can speak for everyone. In fact, I never
commented on the use of exceptions specifically in Subs at all, so are you
sure *you* understood my post?

I don't need to be able to speak for everyone just to say that not
everyone did understand your post. All I need to do is demonstrate a
single person who didn't understand your post, which I've done with Cor
as an example.

I personally didn't read anything into it about Subs.

Well, for a guy that likes precision, you seem to have a problem here. You
wrote to Cor:

"See http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx
for more - it's a good article."

Which tells me you understood and agree with it. I said that I agree with
it as well. What's the problem?

That your original post seems to be a different position. You said to
avoid throwing exceptions for performance reasons - the article
specificially says: "Do not use error codes because of concerns that
exceptions might affect performance negatively."

I think I can be forgiven for believing that you take issue with an
article which explicitly disagrees with your reasoning.

You see those green check marks in the article you mention? You see the red
X's? I interpre the green check marks to mean Yes and the red X's to mean
No.

I'm not at all sure of your point - although interestingly, I don't
have check marks and crosses - I have ys with accents and another
strange character I don't know about. The joy of using Wingdings in a
web page.

I quoted that article myself and summed it up by using the same
terminology in the article (system failure). In fact, I took my comments
directly from the article. Did you even see that post? Interestgly, on
the one hand, you say it's a good article and then on the other you say you
wouldn't use the terminolgy used in the article. Who's being ambiguous now?

I'm saying that if I were writing the article, I wouldn't use that
terminology - but at least in the article, the terminology was
explained.

This whole thing boils down to my mistake (not knowing you would read my
post) by ending my sentence with "when you can." How about this John,

"Exceptions are expensive in terms of CLR performance and so, you should
avoid throwing them arbitrarily."

I'd say that the reasoning is flawed - that shouldn't be the main
reason for not throwing exceptions arbitrarily. Using exceptions for
non-error conditions leads to code which is harder to read. 9 times out
of 10 that's more important than performance.

Give it a rest John, you seem to be the only one hung up on verbiage.
You'll live longer without the stress you put on yourself.

However, other people will be more confused. I've had numerous emails
thanking me for putting to rest doubts people have had due to the
imprecision of others (most specifically about the two topics of pass-
by-reference semantics and "structs are allocated on the stack").

PS - Have you considered a career in law? You'd be great for all that
laywer-speak.

I find there's plenty of mileage in being a pedant in development. An
eye for things which may look correct at first glance but hide flaws is
handy for debugging.

 

[Cor Ligthert [MVP]]

Jon,

Again you are misquoting I once have showed you that placing a message out
of the context of the thread with a text from you by only quoting parts of
the sentences.

My message was written as reply on Scott his message, where he wrote in my
opinion in the context as "try to avoid" and "do as much as possible to do
that".

If you are only able to translate as a computer instead of a human than
special for you I will change that text.

*Try* never to use an exception in a Sub because than giving back a Boolean
*in a Function* an
enum is more describing and as Scott wrote less consuming processing time.

This is a newsgroups, on every message in that everybody can split hairs,
including yours, but probably everybody avoid that, because they know the
reaction on that.

It is also amazing for a developer how many text you can write by probably
trying to put other persons messages in another context and are not able to
translate what is said by what is meant.

Cor

 

[Jon Skeet [C# MVP]]

Again you are misquoting I once have showed you that placing a message out
of the context of the thread with a text from you by only quoting parts of
the sentences.

Again, I don't think there's any real loss of context here. Which part
of which sentence do you think would have made the difference? I do
wish you'd stop accusing me of misquoting without being specific. It's
very tiresome.

My message was written as reply on Scott his message, where he wrote in my
opinion in the context as "try to avoid" and "do as much as possible to do
that".

The interesting thing is the negative attitude towards exceptions
expressed here though - it's all about trying to avoid them rather than
trying to use them where suitable. If you read the article, it's a lot
more positive in the impression it gives about exceptions.

If you are only able to translate as a computer instead of a human than
special for you I will change that text.

*Try* never to use an exception in a Sub because than giving back a Boolean
*in a Function* an enum is more describing and as Scott wrote less consuming
processing time.

Okay, but I *suspect* that's not what he meant either - given that he
mostly agrees with the article, I *suspect* he doesn't actually
recommend using an enum as an error code instead of using an exception.
If he *does* recommend that, then that's disagreeing with the article
again.

(I still completely disagree with you on the idea that enums are more
descriptive than exceptions. The amount of information an enum can give
you is very limiting - exceptions can give as much information as they
want to. That's entirely my opinion, however, and nothing to do with
what Scott has written.)

This is a newsgroups, on every message in that everybody can split hairs,
including yours, but probably everybody avoid that, because they know the
reaction on that.

It is also amazing for a developer how many text you can write by probably
trying to put other persons messages in another context and are not able to
translate what is said by what is meant.

I genuinely didn't know what Scott meant, and I'm quite surprised (but
pleased) now that he's clarified it, given the original post.