Exception vs Boolean

[Shehab Kamal]

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

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

Thanks in advance,
Shehab.

[Cowboy \(Gregory A. Beamer\)]

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*********@di scussions.micro soft.comwrote in message
news:2F******** *************** ***********@mic rosoft.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, NullReferenceEx ception, IndexOutOfRange Exception and so on, or
my
own exceptions be thrown?

Thanks in advance,
Shehab.

[Scott M.]

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.

[Cowboy \(Gregory A. Beamer\)]

You = preacher
Me = choir

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

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

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

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

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

[Jon Skeet [C# MVP]]

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

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.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Cor Ligthert [MVP]]

Jon,

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.co mschreef in bericht
news:MP******** *************** *@msnews.micros oft.com...

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

>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.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

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

[Phil]

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

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

[Cor Ligthert [MVP]]

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.comsch reef in bericht
news:fl******** *************** *********@4ax.c om...

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

>>Jon,

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

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

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

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

Just my thought,

Cor

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

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

[Jon Skeet [C# MVP]]

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