Exceptions: Order of Catch Statements?

[clintonG]

Could someone provide me with a URL documenting the
specific order of exceptions?

--
<%= Clinton Gallagher
A/E/C Consulting, Web Design, e-Commerce Software Development
Wauwatosa, Milwaukee County, Wisconsin USA
NET (e-mail address removed)
URL http://www.metromilwaukee.com/clintongallagher/

 

[Frank Oquendo]

Could someone provide me with a URL documenting the
specific order of exceptions?

From the most specific of your catch blocks to the most general. So an
exception of a specific type would be caught by a matching catch block
rather than a catch set up for something generic like Exception.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[Roy Fine]

Clinton,

I'm not sure that I understand what you are looking for -- but here are two
links
1) catching a thrown exception (straingt from the C# reference)
2) a second that provides good fuel for the recurring, requisite (albeit
pedantic) debate on exceptions that comes up at the weekly .Net cocktail
party

http://msdn.microsoft.com/library/en-us/csspec/html/vclrfcsharpspec_16_3.asp

http://msdn.microsoft.com/library/en-us/dncscol/html/csharp07192001.asp

If this doesn't help, post back with a bit more info on what you are looking
for..

regards
roy fine

 

[clintonG]

Thank you Roy, I'm responding to Frank as he clued in
on 'specifics' which is pertinent to this discussion. Note however
that your [2] reference resulted in leading me to relevant criteria
that you may care to respond to if you climb back up the thread.

<%= Clinton Gallagher

 

[clintonG]

From the most specific of your catch blocks to the most general. So an
exception of a specific type would be caught by a matching catch block
rather than a catch set up for something generic like Exception.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

Thanks for replying Frank. Your correct about specific-to-general
order of operations and I mentioned 'specific order' but was vague
when indicating I am asking how to actually determine specificity.

Using one of Roy's referrals to the C# Language Reference at MSDN
"How exceptions are handled" [1], I was able to use the sidebar menu
to navigate to "Common Exception Classes" [2]. Are we to assume those
common exception classes are listed top-down in order of specificity?
Indications do not support that assumption leaving the determination of
specificity to be determined by other means.

After posting the question -- which is usually the ways it goes -- I found
what seemed to be an answer in the "System Hierarchy" [3]. It seems we
should use the 'specific' derived classes such as DivideByZeroException
rather than the more 'general' ArithmeticException base class which is clear
enough but...

How for example is the developer to determine the specificity of using
DivideByZeroException as opposed to using FormatException?

I imagine one should attempt to catch a FormatException as the implied
circumstances suggest the developer would want to determine if the
correct data type had been submitted before attempting to use that data
in any operation. Thus FormatException would be more specific than
DivideByZeroException. Is this thinking correct?

What page of the documentation is experience listed on?

[1]
http://msdn.microsoft.com/library/d...ry/en-us/csspec/html/vclrfcsharpspec_16_3.asp
[2]
http://msdn.microsoft.com/library/d...ry/en-us/csspec/html/vclrfcsharpspec_16_4.asp
[3]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemhierarchy.asp

<%= Clinton Gallagher

 

[Daniel O'Connell [C# MVP]]

From the most specific of your catch blocks to the most general. So an
exception of a specific type would be caught by a matching catch block
rather than a catch set up for something generic like Exception.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

Thanks for replying Frank. Your correct about specific-to-general
order of operations and I mentioned 'specific order' but was vague
when indicating I am asking how to actually determine specificity.

Using one of Roy's referrals to the C# Language Reference at MSDN
"How exceptions are handled" [1], I was able to use the sidebar menu
to navigate to "Common Exception Classes" [2]. Are we to assume those
common exception classes are listed top-down in order of specificity?
Indications do not support that assumption leaving the determination of
specificity to be determined by other means.

After posting the question -- which is usually the ways it goes -- I found
what seemed to be an answer in the "System Hierarchy" [3]. It seems we
should use the 'specific' derived classes such as DivideByZeroException
rather than the more 'general' ArithmeticException base class which is clear
enough but...

How for example is the developer to determine the specificity of using
DivideByZeroException as opposed to using FormatException?

I imagine one should attempt to catch a FormatException as the implied
circumstances suggest the developer would want to determine if the
correct data type had been submitted before attempting to use that data
in any operation. Thus FormatException would be more specific than
DivideByZeroException. Is this thinking correct?

They are different things and therefore have the same specificity. For this
example consider specificity as the distance from Exception. The further
away from Exception you are in the current family the more specific you are.
DivideByZeroException is more specific than ArithmeticException which is
more specific than SystemException which is more specific than Exception,
however a catch block of any of those types will catch an exception of type
DivideByZeroException. They are just less specific.
FormatException is more specific than SystemException, but is not related to
DivideByZeroException in any way.

What page of the documentation is experience listed on?

[1]
http://msdn.microsoft.com/library/d...ry/en-us/csspec/html/vclrfcsharpspec_16_3.asp

[2]

http://msdn.microsoft.com/library/d...ry/en-us/csspec/html/vclrfcsharpspec_16_4.asp

[3]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemhierarchy.asp

<%= Clinton Gallagher

 

[clintonG]

clintonG wrote:
Could someone provide me with a URL documenting the
specific order of exceptions?

From the most specific of your catch blocks to the most general. So an
exception of a specific type would be caught by a matching catch block
rather than a catch set up for something generic like Exception.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

Thanks for replying Frank. Your correct about specific-to-general
order of operations and I mentioned 'specific order' but was vague
when indicating I am asking how to actually determine specificity.

Using one of Roy's referrals to the C# Language Reference at MSDN
"How exceptions are handled" [1], I was able to use the sidebar menu
to navigate to "Common Exception Classes" [2]. Are we to assume those
common exception classes are listed top-down in order of specificity?
Indications do not support that assumption leaving the determination of
specificity to be determined by other means.

After posting the question -- which is usually the ways it goes -- I found
what seemed to be an answer in the "System Hierarchy" [3]. It seems we
should use the 'specific' derived classes such as DivideByZeroException
rather than the more 'general' ArithmeticException base class which is clear
enough but...

How for example is the developer to determine the specificity of using
DivideByZeroException as opposed to using FormatException?

I imagine one should attempt to catch a FormatException as the implied
circumstances suggest the developer would want to determine if the
correct data type had been submitted before attempting to use that data
in any operation. Thus FormatException would be more specific than
DivideByZeroException. Is this thinking correct?

They are different things and therefore have the same specificity. For this
example consider specificity as the distance from Exception. The further
away from Exception you are in the current family the more specific you are.
DivideByZeroException is more specific than ArithmeticException which is
more specific than SystemException which is more specific than Exception,
however a catch block of any of those types will catch an exception of type
DivideByZeroException. They are just less specific.
FormatException is more specific than SystemException, but is not related to
DivideByZeroException in any way.

What page of the documentation is experience listed on?

[1]

http://msdn.microsoft.com/library/d...ry/en-us/csspec/html/vclrfcsharpspec_16_3.asp

[2]

http://msdn.microsoft.com/library/d...ry/en-us/csspec/html/vclrfcsharpspec_16_4.asp

[3]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemhierarchy.asp

<%= Clinton Gallagher

Sounds to me like you describe specificity as a subclassed hierarchical
relationship
of the System.Exception base class. When I see it that way as indicated via
[3] that
is what I need to confirm as careful reading of System.Exception states
"...a catch block
that handles a type must be specified before a catch block that handles its
base types..."
which really helps puts specificity into perspective.

<%= Clinton Gallagher

 

[Daniel O'Connell [C# MVP]]

They are different things and therefore have the same specificity. For this
example consider specificity as the distance from Exception. The further
away from Exception you are in the current family the more specific you are.
DivideByZeroException is more specific than ArithmeticException which is
more specific than SystemException which is more specific than Exception,
however a catch block of any of those types will catch an exception of type
DivideByZeroException. They are just less specific.
FormatException is more specific than SystemException, but is not

related

to
DivideByZeroException in any way.

What page of the documentation is experience listed on?

[1]

http://msdn.microsoft.com/library/d...ry/en-us/csspec/html/vclrfcsharpspec_16_3.asp

[2]

http://msdn.microsoft.com/library/d...ry/en-us/csspec/html/vclrfcsharpspec_16_4.asp

[3]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemhierarchy.asp
Sounds to me like you describe specificity as a subclassed hierarchical
relationship
of the System.Exception base class. When I see it that way as indicated via
[3] that
is what I need to confirm as careful reading of System.Exception states
"...a catch block
that handles a type must be specified before a catch block that handles its
base types..."
which really helps puts specificity into perspective.

Ya, that isn't the clearest writing you'll see. If you try to compile
something like
try
{

}
catch (Exception)
{
}
catch (SecurityException)
{
}

the compiler will produce an error. The first handler an exception
encounters that can handle it will be called, C# merely attempts to force
you to write code without a bug like above(technically *EVERY* exception
would be caught by the first handler and the second would never be called).
Becauseof that you have to put more specific(further derived\subclassed)
exception handlers first.

 

[clintonG]

They are different things and therefore have the same specificity. For this
example consider specificity as the distance from Exception. The further
away from Exception you are in the current family the more specific

you
are.

DivideByZeroException is more specific than ArithmeticException which is
more specific than SystemException which is more specific than Exception,
however a catch block of any of those types will catch an exception of type
DivideByZeroException. They are just less specific.
FormatException is more specific than SystemException, but is not

related

to
DivideByZeroException in any way.

What page of the documentation is experience listed on?

[1]

http://msdn.microsoft.com/library/d...ry/en-us/csspec/html/vclrfcsharpspec_16_3.asp

[2]

http://msdn.microsoft.com/library/d...ry/en-us/csspec/html/vclrfcsharpspec_16_4.asp

[3]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemhierarchy.asp

<%= Clinton Gallagher

Sounds to me like you describe specificity as a subclassed hierarchical
relationship
of the System.Exception base class. When I see it that way as indicated via
[3] that
is what I need to confirm as careful reading of System.Exception states
"...a catch block
that handles a type must be specified before a catch block that handles its
base types..."
which really helps puts specificity into perspective.

Ya, that isn't the clearest writing you'll see. If you try to compile
something like
try
{

}
catch (Exception)
{
}
catch (SecurityException)
{
}

the compiler will produce an error. The first handler an exception
encounters that can handle it will be called, C# merely attempts to force
you to write code without a bug like above(technically *EVERY* exception
would be caught by the first handler and the second would never be called).
Becauseof that you have to put more specific(further derived\subclassed)
exception handlers first.

<%= Clinton Gallagher

I read myself to sleep again last night and learned exactly what you point
out Daniel.

<%= Clinton Gallagher