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.

[Siva M]

From the horse mouth:
http://blogs.msdn.com/kcwalina/archi...16/396787.aspx

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

[Shehab Kamal]

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.

[Scott M.]

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*********@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.]

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*********@di scussions.micro soft.comwrote in message
news:CA******** *************** ***********@mic rosoft.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.

[Siva M]

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
CustomerNotFoun d 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*********@di scussions.micro soft.comwrote in message
news:CA******** *************** ***********@mic rosoft.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.

[Barry Kelly]

Shehab Kamal <Sh*********@di scussions.micro soft.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/

[Barry Kelly]

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

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>.TryGet Value. 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/

[Jon Skeet [C# MVP]]

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

[Scott M.]

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.co mwrote in message
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