Re: Exception vs Boolean

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

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]" <skeet@xxxxxxxxx> schreef in bericht
news:MPG.1f4aff236326b56b98d3d1@xxxxxxxxxxxxxxxxxxxxxxx
Scott M. <s-mar@xxxxxxxxxxxxx> wrote:
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 re*** 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 - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too


.

Quantcast