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, NullReferenceException, IndexOutOfRangeException and so on, or my
own exceptions be thrown?
Thanks in advance,
Shehab.
43  2071 
From the horse mouth: http://blogs.msdn.com/kcwalina/archi...16/396787.aspx
"Shehab Kamal" <Sh*********@discussions.microsoft.comwrote in message
news:2F**********************************@microsof t.com...
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, NullReferenceException, IndexOutOfRangeException and so on, or
my
own exceptions be thrown?
Thanks in advance,
Shehab.
I'm really convinced that I should throw my own custom exceptions but the
article sates that "Do not create and throw new exceptions just to have ‘your
team's’ exception".
Do you have more resources about throwing custom exceptions? When and when
not to use them?
Thanks in advance,
Shehab.
Exceptions are expensive in terms of CLR performance and so, you should
avoid throwing them when you can.
If you decide that an exception is what you need, you can certainly use the
built-in exception types if they fit your situation or you can certainly
create a custom exception based on one of the built-in exception classes.
"Shehab Kamal" <Sh*********@discussions.microsoft.comwrote in message
news:2F**********************************@microsof t.com...
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, NullReferenceException, IndexOutOfRangeException and so on, or
my
own exceptions be thrown?
Thanks in advance,
Shehab.
I think that article sums it up quite nicely:
Do not use exceptions for normal execution flow.
Do use exeptions for system failures.
"Shehab Kamal" <Sh*********@discussions.microsoft.comwrote in message
news:CA**********************************@microsof t.com...
I'm really convinced that I should throw my own custom exceptions but the
article sates that "Do not create and throw new exceptions just to have
'your
team's' exception".
Do you have more resources about throwing custom exceptions? When and when
not to use them?
Thanks in advance,
Shehab.
Custom exceptions are generally useful for indicating businesss-specific
error conditions. For example, if a request is made to create a Customer
object with an invalid customer ID, you could raise a custom exception, say
CustomerNotFound exception which could in turn be caught and handled by the
calling layer. However, .NET Framework already comes with many exception
types and make sure none of them fit your case before proceeding with
creating your own.
Take a look at this (& the sub-topics) anyway: http://msdn2.microsoft.com/en-us/library/ms229014.aspx
"Shehab Kamal" <Sh*********@discussions.microsoft.comwrote in message
news:CA**********************************@microsof t.com...
I'm really convinced that I should throw my own custom exceptions but the
article sates that "Do not create and throw new exceptions just to have
‘your
team's’ exception".
Do you have more resources about throwing custom exceptions? When and when
not to use them?
Thanks in advance,
Shehab.
Shehab Kamal <Sh*********@discussions.microsoft.comwrote:
I'm really convinced that I should throw my own custom exceptions but the
article sates that "Do not create and throw new exceptions just to have ‘your
team's’ exception".
Do you have more resources about throwing custom exceptions? When and when
not to use them?
If code calling your methods can have meaningful behaviour based on the
exception type, then it makes sense to throw a particular exception
type. For example, when downloading a file, the errors 'host not found'
and 'timeout occurred on connect' are different and the program can take
different behaviours for them. For a timeout, it can retry - but if the
host isn't found, it's unlikely to be found with a retry. Thus, there
should be a different exception thrown for the two cases.
-- Barry
-- http://barrkel.blogspot.com/
"Scott M." <s-***@nospam.nospamwrote:
Exceptions are expensive in terms of CLR performance and so, you should
avoid throwing them when you can.
I'd advise measuring before taking drastic action to remove them from
your code. Propagating meaningful error information up the stack is more
expensive in pretty much every way than exceptions: more code to
maintain, more rigorous coding standard required, every called function
needs to propagate the return value, need to convert properties into
methods so that a separate return value can be used for the error, can't
write simple expressions like 'a.Prop1 + b.Prop2' because properties
turn into methods with 'out' parameters, etc.
I would strongly prefer exceptions to error codes unless it's easy to
use a semantic two-way (i.e. test and perform) operation instead, like
int.TryParse and Dictionary<TKey,TValue>.TryGetValue. These are best
suited to 'leaf' operations, operations that don't go off and call some
deep graph of other methods.
-- Barry
-- http://barrkel.blogspot.com/
Scott M. <s-***@nospam.nospamwrote:
Exceptions are expensive in terms of CLR performance and so, you should
avoid throwing them when you can.
You can *always* avoid throwing them though - your advice, taken
literally, translates to "Never throw exceptions". Consider what would
have happened if the framework designers had followed your advice for
FileStreams. If a file didn't exist when you asked to open it, you
could get a "null stream" which silently returned no data. You could
then check a property to see whether everything was okay or not. That
would avoid throwing exceptions - but would have been *terribly* for
robustness.
Yes, exceptions are expensive compared with a normal return - but if
used properly, they should indicate an error situation which means that
performance is likely to be unimportant at that point. If you have a
tight loop which throws thousands of exceptions then at *that* point
exceptions will make a significant difference - but then the situation
isn't exceptional.
The performance penalty of exceptions has been hugely overstated, I
believe mostly because it's so large for the first exception thrown
when debugging.
See http://www.pobox.com/~skeet/csharp/exceptions.html for more on
this.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
No Jon, my advice taken literally is exactly what I said "you should avoid
them when you can". Your interpretation of that was "don't use them because
tyhey can always be avoided".
But, obviously (as you point out) avoiding an exception could cause other
problems down the line. In my opinion, that would fall into the "I guess I
need this exception and shouldn't avoid it" camp.
My advice was based on the OP, return a value vs. throw an exception. The
point was don't just throw an exception because you can. Also, if you see
my other comment in the branch thread, you'll see I qualify my point
further.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Scott M. <s-***@nospam.nospamwrote:
>Exceptions are expensive in terms of CLR performance and so, you should
avoid throwing them when you can.
You can *always* avoid throwing them though - your advice, taken
literally, translates to "Never throw exceptions". Consider what would
have happened if the framework designers had followed your advice for
FileStreams. If a file didn't exist when you asked to open it, you
could get a "null stream" which silently returned no data. You could
then check a property to see whether everything was okay or not. That
would avoid throwing exceptions - but would have been *terribly* for
robustness.
Yes, exceptions are expensive compared with a normal return - but if
used properly, they should indicate an error situation which means that
performance is likely to be unimportant at that point. If you have a
tight loop which throws thousands of exceptions then at *that* point
exceptions will make a significant difference - but then the situation
isn't exceptional.
The performance penalty of exceptions has been hugely overstated, I
believe mostly because it's so large for the first exception thrown
when debugging.
See http://www.pobox.com/~skeet/csharp/exceptions.html for more on
this.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
1. Never use catch unless you are doing something with the error
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
3. If you are not catching exceptions, do not add a catch simply to throw a
custom exception, UNLESS your exception will better explain the problem
(this can go back to checking input variables, ala rule #2).
In most cases, it is better to have your own exceptions except in cases
where you have NOTHING to add to the mix. If there are any business rules,
even if they cause SQL exceptions, create your own exception.
In the world of OO, this is part of encapsulation.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*************************************************
Think outside the box!
*************************************************
"Shehab Kamal" <Sh*********@discussions.microsoft.comwrote in message
news:2F**********************************@microsof t.com...
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, NullReferenceException, IndexOutOfRangeException and so on, or
my
own exceptions be thrown?
Thanks in advance,
Shehab.
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.
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.nospamwrote in message
news:eL**************@TK2MSFTNGP03.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.
Scott M. <s-***@nospam.nospamwrote:
No Jon, my advice taken literally is exactly what I said "you should avoid
them when you can". Your interpretation of that was "don't use them because
tyhey can always be avoided".
Well, do you not agree that they *can* always be avoided? After all,
there are millions of lines of C out there which don't use exceptions,
using status codes instead.
I can't think of many cases where you *have* to throw an exception -
you *can* almost always avoid throwing them, but that doesn't mean you
*should* avoid throwing them in all those situations.
But, obviously (as you point out) avoiding an exception could cause other
problems down the line. In my opinion, that would fall into the "I guess I
need this exception and shouldn't avoid it" camp.
Right - and in that case you *can* avoid it, but shouldn't. To my mind,
that goes against your advice.
My advice was based on the OP, return a value vs. throw an exception. The
point was don't just throw an exception because you can.
Don't you see that there's a *huge* difference between "avoid
exceptions if you can" and "don't throw exceptions pointlessly"?
The trouble is, I can imagine lots of developers considering whether to
use an error code or an exception. I can't see how they could read your
advice without coming to the conclusion that you'd favour using an
error code - which is almost always a worse way of indicating errors
than using exceptions.
Obviously exceptions shouldn't be thrown just for the hell of it - but
I don't think they should be actively avoided, either.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...
Scott M. <s-***@nospam.nospamwrote:
>Exceptions are expensive in terms of CLR performance and so, you should
avoid throwing them when you can.
You can *always* avoid throwing them though - your advice, taken
literally, translates to "Never throw exceptions". Consider what would
have happened if the framework designers had followed your advice for
FileStreams. If a file didn't exist when you asked to open it, you
could get a "null stream" which silently returned no data. You could
then check a property to see whether everything was okay or not. That
would avoid throwing exceptions - but would have been *terribly* for
robustness.
Yes, exceptions are expensive compared with a normal return - but if
used properly, they should indicate an error situation which means that
performance is likely to be unimportant at that point. If you have a
tight loop which throws thousands of exceptions then at *that* point
exceptions will make a significant difference - but then the situation
isn't exceptional.
The performance penalty of exceptions has been hugely overstated, I
believe mostly because it's so large for the first exception thrown
when debugging.
See http://www.pobox.com/~skeet/csharp/exceptions.html for more on
this.
--
Jon Skeet - <sk***@pobox.com>
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] wrote:
In my idea is the well written text from Scott, completely clear.
This is interesting, given that his clarification suggests that your
interpretation was not what was actually meant...
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.
No, a boolean or enum is *not* more descriptive than an exception. An
exception can give as much information as you want it to - a boolean or
an enum is a single value. Furthermore, turning the sub into a function
with a status code then demands that every call to it should check the
status code (assuming they care about error handling).
Do you really want to have to check a status code every time you add an
entry to a list?
Performance is a separate issue - have you read my page on it? Do you
have any experience of real life situations where exceptions were only
thrown in ways which most people would deem "reasonable" but where
performance was an issue?
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).
Well, I'm very glad you weren't part of designing the framework
classes. You'll find very few status codes there, and plenty of
exceptions being thrown by void methods.
Jon
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
Well, I'm very glad you weren't part of designing the framework
classes. You'll find very few status codes there, and plenty of
exceptions being thrown by void methods.
http://msdn.microsoft.com/library/de...classtopic.asp
Before you start telling this is not returning an *error*.
An error is not something special, it is just something on what an action
would be taken.
Cor
Phil,
I was specially folowing the thread from Scott.
He has not written that an error should be thrown for ever.
I was writting in the situation that you needed to return a possible error
and than you have in the case of a VB Sub. (I think it is confusing telling
this as a not Void method in C# because that does not tell direct the right
situation.) to return an class object including the error or to throw an
exception. (It is as well possible to pass an empty boolean variable by
value but that *I* find a bad way of programming).
See this link I showed to Jon as well, and see that it has only to be need
if there has to be checked for an error, what is written about this by Scott
as well. http://msdn.microsoft.com/library/de...classtopic.asp
Cor
"Phil" <fo*@foo.comschreef in bericht
news:fl********************************@4ax.com...
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
Cor Ligthert [MVP] wrote:
Well, I'm very glad you weren't part of designing the framework
classes. You'll find very few status codes there, and plenty of
exceptions being thrown by void methods.
http://msdn.microsoft.com/library/de...classtopic.asp
Before you start telling this is not returning an *error*.
An error is not something special, it is just something on what an action
would be taken.
I'm not sure which part of OpenFileDialog you're referring to, to be
honest. However, there are certainly situations where there can be
different statuses which don't mean that the call failed, just that
there are legitimate different non-error statuses.
Do you want me to give a list of subs which *do* throw exceptions
rather than returning status codes? I note you didn't answer about
having to check a status after calling ArrayList.Add each time...
Jon
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
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 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 :-)
--
Phil
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.Insert which takes
an index which must be validated?
Jon
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.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.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.Insert which takes
an index which must be validated?
Jon
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.comwrote in message
news:fl********************************@4ax.com...
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
Sorry Greg, I was just adding to your comments for Shehab.
"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamMwrote in
message news:e1**************@TK2MSFTNGP05.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.nospamwrote in message
news:eL**************@TK2MSFTNGP03.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.
On Mon, 14 Aug 2006 17:28:37 -0400, "Scott M." <s-***@nospam.nospam>
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
Scott M. <s-***@nospam.nospamwrote:
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.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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.comschreef in bericht
news:MP************************@msnews.microsoft.c om...
Scott M. <s-***@nospam.nospamwrote:
>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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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.nlschreef in bericht
news:O4****************@TK2MSFTNGP04.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.comschreef in bericht
news:MP************************@msnews.microsoft.c om...
>Scott M. <s-***@nospam.nospamwrote:
>>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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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.
"Phil" <fo*@foo.comwrote in message
news:8h********************************@4ax.com...
On Mon, 14 Aug 2006 17:28:37 -0400, "Scott M." <s-***@nospam.nospam>
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
Cor Ligthert [MVP] <no************@planet.nlwrote:
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
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.
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.
Do not return error codes. Exceptions are the primary means of reporting
errors in frameworks."
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/archi...16/396787.aspx
for more - it's a good article.
--
Jon Skeet - <sk***@pobox.com> 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] <no************@planet.nlwrote:
By the way, if Scott wrote this somewhere,
Do not return error codes. Exceptions are the primary means of reporting
errors in frameworks."
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 - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Scott M. <s-***@nospam.nospamwrote:
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Cor Ligthert [MVP] <no************@planet.nlwrote:
>By the way, if Scott wrote this somewhere,
>Do not return error codes. Exceptions are the primary means of reporting
errors in frameworks."
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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/archi...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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Scott M. <s-***@nospam.nospamwrote:
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 - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Scott M. <s-***@nospam.nospamwrote:
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.
But don't you see that his response backs up my claim that your post
was ambiguous?
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.
I think you're the one splitting hairs now, between saying to avoid
throwing exceptions and not explicitly saying not to use them.
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?
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.
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/archi...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.
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'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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...
Scott M. <s-***@nospam.nospamwrote:
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.
But don't you see that his response backs up my claim that your post
was ambiguous?
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.
I think you're the one splitting hairs now, between saying to avoid
throwing exceptions and not explicitly saying not to use them.
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?
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.
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/archi...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.
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'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.
--
Jon Skeet - <sk***@pobox.com>
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] <no************@planet.nlwrote:
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Inline
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
Cor Ligthert [MVP] <no************@planet.nlwrote:
>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.
I thought I cleared that in the rest of my previous message. To clarify that
even more confirm my ideas about that.
There have been in history and sadly still is done lots of situations where
(especially) the christian bible but I thought as well the koran are
misquoted by people, that has/does given many killings. Something that in my
opinion is completely in disharmony with the ideas of the main persons who
are quoted.
It are not only the words that are written but the intention from the
original quoted person that should count. But probably we disagree about
that as well.
>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.
I have expressely added my reply to the first reply from you where there was
not spoken about the article and not to that other thread. Thereby avoiding
that discussion. The first answer from Scott was a very clear text for me.
If you want to say that he did not wanted to say that, than I think that you
should not say that but Scott. This kind of talking for others I call
misquoting, because these messages stay and stand alone they give an opinion
as if Scott said that, while it was in my opinion you. If Scott says that
his first text was not meant as written, he is as far as I have seen his
message very good able to correct 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.
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.
See my previous inline answer in this message.
(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 in my opinion an exact answer that I did not wished to give in this
message thread. Accoording to my way of thinking. If you are not able to use
a boolean or a simple Enum, than you certainly should start thinking about
an exception. I did not write this because it was in my idea obvious in the
context of the other text I had written and still in the style of Scotts
first message.
>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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Typo
I have seen his message = I have seen his messages (in past)
"Cor Ligthert [MVP]" <no************@planet.nlschreef in bericht
news:%2****************@TK2MSFTNGP03.phx.gbl...
Inline
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
>Cor Ligthert [MVP] <no************@planet.nlwrote:
>>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.
I thought I cleared that in the rest of my previous message. To clarify
that even more confirm my ideas about that.
There have been in history and sadly still is done lots of situations
where (especially) the christian bible but I thought as well the koran are
misquoted by people, that has/does given many killings. Something that in
my opinion is completely in disharmony with the ideas of the main persons
who are quoted.
It are not only the words that are written but the intention from the
original quoted person that should count. But probably we disagree about
that as well.
>>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.
I have expressely added my reply to the first reply from you where there
was not spoken about the article and not to that other thread. Thereby
avoiding that discussion. The first answer from Scott was a very clear
text for me. If you want to say that he did not wanted to say that, than I
think that you should not say that but Scott. This kind of talking for
others I call misquoting, because these messages stay and stand alone they
give an opinion as if Scott said that, while it was in my opinion you. If
Scott says that his first text was not meant as written, he is as far as I
have seen his message very good able to correct 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.
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.
See my previous inline answer in this message.
>(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 in my opinion an exact answer that I did not wished to give in
this message thread. Accoording to my way of thinking. If you are not able
to use a boolean or a simple Enum, than you certainly should start
thinking about an exception. I did not write this because it was in my
idea obvious in the context of the other text I had written and still in
the style of Scotts first message.
>>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.
--
Jon Skeet - <sk***@pobox.com>
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] wrote:
Inline
<snip>
Almost needless to say, I still disagree. I don't think we're getting
anywhere here, so I'll drop it at this point.
Jon
Jon,
No problem, does not give any hard feeling from me.
Rome is as well not build in one day.
:-)
Cor
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:11**********************@m73g2000cwd.googlegr oups.com...
Cor Ligthert [MVP] wrote:
>Inline
<snip>
Almost needless to say, I still disagree. I don't think we're getting
anywhere here, so I'll drop it at this point.
Jon
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Diego F. |
last post by:
I think I'll never come across that error. It happens when running code from
a DLL that tries to write to disk. I added permissions in the project
folder, the wwwroot and in IIS to NETWORK_SERVICE...
|
by: Steve Long |
last post by:
Help,
I'm running VS.NET 2003 and when I try to start my application, I get the
"unhandled exception" dialog instead of the IDE highlighting the offending
line of code. The problem appears to be...
|
by: David Herbst |
last post by:
Enterprise Library Jan 2006 with Visual Studio 2005 on Windows 2000
Server sp4.
My custom exception formatter fails with a "Unable to handle exception:
'LoggingExceptionHandler'." exception. ...
|
by: Shimon Sim |
last post by:
I just switch my asp application to .net 2 and got this error. Any reasons
why?
Thank you.
Server Error in '/RAFEmployee' Application....
|
by: alf |
last post by:
I have an app that was running in my local server using full trust, now I
moved it to hosting company wish run in Medium trust.
Then I get a Security exception (details below)
Then I configured...
|
by: cozsmin |
last post by:
hello , as u know wait() and notify() will not thow an exception if the method that calls them has the lock , or esle i misundrestood java :P
this is the code that throws (unwanted) ...
|
by: Mike |
last post by:
Hi
I have problem as folow:
Caught Exception: System.Configuration.ConfigurationErrorsException:
An error occurred loading a configuration file: Request for the
permission of type...
|
by: star111792 |
last post by:
helo all
i am working with JSP and EJBs. i have written a simple code for verifying username and password of user by using session beans. my problem is that i am getting the following exception:
...
|
by: yogarajan |
last post by:
The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack...
|
by: chandhrakv |
last post by:
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 11/18/2009 3:03:53 PM
Event time (UTC): 11/18/2009 9:33:53 AM
Event ID: ef3014ea80424b00b1bc2e7095fffe4c ...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
