Re: Exception vs Boolean

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

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