Exceptions in Business Classes

[Knut Vonheim]

Hi all,

I am trying to decide how to best handle exceptions in Business Classes. For
example, there are times when public properties have valid ranges of values
and enumerations are not feasible.

What is the best way to handle these? Throw an exception such as an
ApplicationException? Do you handle it differently if the property will be
bound to UI Control?

Any hints, pointers, or guidance is greatly appreciated!

Cheers,

Knut

[Daniel Pratt]

Hi Knut,

"Knut Vonheim" <vo*****@msn.com> wrote in message
news:OL**************@tk2msftngp13.phx.gbl...

Hi all,

I am trying to decide how to best handle exceptions in Business Classes. For example, there are times when public properties have valid ranges of values and enumerations are not feasible.

What is the best way to handle these? Throw an exception such as an
ApplicationException? Do you handle it differently if the property will be
bound to UI Control?

Any hints, pointers, or guidance is greatly appreciated!

In the specific example you give, I would use
System.ArgumentOutOfRangeException. I would also suggest that you avoid
using ApplicationException. The problem with ApplicationException is that
it's too generic. There's no reasonable case (that I can see) for handling
an ApplicationException any differently than the base Exception class. A
recent post in Brad Abrams' blog points this out (very good blog, btw):

http://blogs.msdn.com/brada/archive/.../25/96251.aspx

Regards,
Daniel

[Knut Vonheim]

Daniel,

thanks for the input! I am looking into your suggestion and reading up on
the link.

The one thing I will do is to sure all my exceptions have the same base
class. I have a suspicion the reason Microsoft is recommending using
application exception class is some future change they will make. However,
as pointed out in the blog, as long as they are from the same class the
change is easy to make at that time.

Thanks again!

Cheers,

Knut
"Daniel Pratt" <ko******************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Hi Knut,

"Knut Vonheim" <vo*****@msn.com> wrote in message
news:OL**************@tk2msftngp13.phx.gbl...

Hi all,

I am trying to decide how to best handle exceptions in Business Classes.

For

example, there are times when public properties have valid ranges of

values

and enumerations are not feasible.

What is the best way to handle these? Throw an exception such as an
ApplicationException? Do you handle it differently if the property will be bound to UI Control?

Any hints, pointers, or guidance is greatly appreciated!

In the specific example you give, I would use
System.ArgumentOutOfRangeException. I would also suggest that you avoid
using ApplicationException. The problem with ApplicationException is that
it's too generic. There's no reasonable case (that I can see) for handling
an ApplicationException any differently than the base Exception class. A
recent post in Brad Abrams' blog points this out (very good blog, btw):

http://blogs.msdn.com/brada/archive/.../25/96251.aspx

Regards,
Daniel

[Daniel Pratt]

Hi Knut,

"Knut Vonheim" <vo*****@msn.com> wrote in message
news:eJ**************@tk2msftngp13.phx.gbl...

Daniel,

thanks for the input! I am looking into your suggestion and reading up on
the link.

The one thing I will do is to sure all my exceptions have the same base
class. I have a suspicion the reason Microsoft is recommending using
application exception class is some future change they will make. However,
as pointed out in the blog, as long as they are from the same class the
change is easy to make at that time.

Creating a common base class for all your exceptions is certainly your
option, but you should know that the same people who told you to inherit all
your exceptions from a common base class (i.e. ApplicationException) are now
saying don't bother; Inherit from System.Exception instead. Krystof Cwalina
(Program Manager for the .NET CLR) writes:

"Well-designed exception hierarchies are wide, not very deep, and
contain only those exceptions for which there is a programmatic scenario for
catching."

The ApplicationException class isn't about protecting against future
changes. Rather it's a decision the designers of the .NET framework wouldn't
make if they had the chance to do it over again. Hindsight 20-20 and all
that.

Regards,
Daniel

[Knut Vonheim]

Daniel,

thanks for the input! I am looking into your suggestion and reading up on
the link.

The one thing I will do is to sure all my exceptions have the same base
class. I have a suspicion the reason Microsoft is recommending using
application exception class is some future change they will make. However,
as pointed out in the blog, as long as they are from the same class the
change is easy to make at that time.

Thanks again!

Cheers,

Knut
"Daniel Pratt" <ko******************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Hi Knut,

"Knut Vonheim" <vo*****@msn.com> wrote in message
news:OL**************@tk2msftngp13.phx.gbl...

Hi all,

I am trying to decide how to best handle exceptions in Business Classes.

For

example, there are times when public properties have valid ranges of

values

and enumerations are not feasible.

What is the best way to handle these? Throw an exception such as an
ApplicationException? Do you handle it differently if the property will be bound to UI Control?

Any hints, pointers, or guidance is greatly appreciated!

In the specific example you give, I would use
System.ArgumentOutOfRangeException. I would also suggest that you avoid
using ApplicationException. The problem with ApplicationException is that
it's too generic. There's no reasonable case (that I can see) for handling
an ApplicationException any differently than the base Exception class. A
recent post in Brad Abrams' blog points this out (very good blog, btw):

http://blogs.msdn.com/brada/archive/.../25/96251.aspx

Regards,
Daniel

[Daniel Pratt]

Hi Knut,

"Knut Vonheim" <vo*****@msn.com> wrote in message
news:eJ**************@tk2msftngp13.phx.gbl...

Daniel,

thanks for the input! I am looking into your suggestion and reading up on
the link.

The one thing I will do is to sure all my exceptions have the same base
class. I have a suspicion the reason Microsoft is recommending using
application exception class is some future change they will make. However,
as pointed out in the blog, as long as they are from the same class the
change is easy to make at that time.

Creating a common base class for all your exceptions is certainly your
option, but you should know that the same people who told you to inherit all
your exceptions from a common base class (i.e. ApplicationException) are now
saying don't bother; Inherit from System.Exception instead. Krystof Cwalina
(Program Manager for the .NET CLR) writes:

"Well-designed exception hierarchies are wide, not very deep, and
contain only those exceptions for which there is a programmatic scenario for
catching."

The ApplicationException class isn't about protecting against future
changes. Rather it's a decision the designers of the .NET framework wouldn't
make if they had the chance to do it over again. Hindsight 20-20 and all
that.

Regards,
Daniel

[Jeffrey Tan[MSFT]]

Hi Knut,

Do you still have any concern on this issue?

Please feel free to let me know. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Knut Vonheim]

Jeffrey,

I am working through the documentation on interfaces and CollectionBase.

I guess my question was a little broad, but I did receive some pointers to
documentation so I am working through it.

If I have more specific questions I will post in this forum.

Thanks again for following up, though!

Cheers,

Knut
""Jeffrey Tan[MSFT]"" <v-*****@online.microsoft.com> wrote in message
news:9s*************@cpmsftngxa06.phx.gbl...

Hi Knut,

Do you still have any concern on this issue?

Please feel free to let me know. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Knut,

Do you still have any concern on this issue?

Please feel free to let me know. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Knut Vonheim]

Jeffrey,

I am working through the documentation on interfaces and CollectionBase.

I guess my question was a little broad, but I did receive some pointers to
documentation so I am working through it.

If I have more specific questions I will post in this forum.

Thanks again for following up, though!

Cheers,

Knut
""Jeffrey Tan[MSFT]"" <v-*****@online.microsoft.com> wrote in message
news:9s*************@cpmsftngxa06.phx.gbl...

Hi Knut,

Do you still have any concern on this issue?

Please feel free to let me know. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Knut,

Thanks for your feedback.

Yes, I hope you can find all you want through your research.

Anyway, you can feel free to post, the community will help you. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.