Exception Handling - the pragmatics 
Author Message
 Exception Handling - the pragmatics

I have a .Net DLL which needs to pass back to a caller one of a number of
possible result codes, for each of its methods called.

Currently I am passing these back via the Return statement.  Some of the
return values are represent serious problems and should probably be raised
as exceptions to the DLL caller - some return codes are not that serious.

I have two questions on this.

1.  Should I define an exception class for every return code which needs to
be raised?  Bearing in mind the large number of possible excepions which
could be raised, is it better/possible to define a single Exception class
for my DLL and have the caller read a property to determine the code.

2. How religious should I be about returning all codes this way.  In other
words should I use Subs and assume success unless an exception occurrs, or
is it acceptable to pass information back via function return codes for
situations which do not represent critical failure.

Any comments gratefully accepted.

Mart



Tue, 20 Sep 2005 14:41:15 GMT  
 Exception Handling - the pragmatics
From a purist (and my own) point of view, methods should return objects /
values that pertain to the class's / method's business model, not some class
/ value indicating levels of success and failure. It's not really the way
objects interact. Generally, objects call other functions, and expect the
call to suceed. A failure can be expressed through the use of exceptions.

It's certainly a matter of taste. I work with people who have practically
every method returning a bool or custom error class, and use out parameters
extensively. To me, forcing clients to repeatedly branch on the return type
of functions promotes procedural program flow.

Regards,

4Space

Quote:
> I have a .Net DLL which needs to pass back to a caller one of a number of
> possible result codes, for each of its methods called.

> Currently I am passing these back via the Return statement.  Some of the
> return values are represent serious problems and should probably be raised
> as exceptions to the DLL caller - some return codes are not that serious.

> I have two questions on this.

> 1.  Should I define an exception class for every return code which needs
to
> be raised?  Bearing in mind the large number of possible excepions which
> could be raised, is it better/possible to define a single Exception class
> for my DLL and have the caller read a property to determine the code.

> 2. How religious should I be about returning all codes this way.  In other
> words should I use Subs and assume success unless an exception occurrs, or
> is it acceptable to pass information back via function return codes for
> situations which do not represent critical failure.

> Any comments gratefully accepted.

> Mart



Tue, 20 Sep 2005 15:35:13 GMT  
 Exception Handling - the pragmatics
Mart,

Personally, I would go in for creating custom exception classes.

It's better if you divide your errors into categories and create classes for
each category. Within these, denote various errors/msgs with unique
pre-determined "error codes". For e.g.; for critical errors, dedictate
numbers 101-999. For non-critical errors, keep numbers 01-99 and so on.

Then, throw the exceptions and pass the number to the constructor. In the
exception class, based on the number, throw the msg.

Let the client app "catch" the exception and decide what to do with it.
Based on the number, they can determine if it's a critical error or not by
checking the property of the exception.

Hope this gets you started.

Ajay Singala [Synergetics]


Quote:
> I have a .Net DLL which needs to pass back to a caller one of a number of
> possible result codes, for each of its methods called.

> Currently I am passing these back via the Return statement.  Some of the
> return values are represent serious problems and should probably be raised
> as exceptions to the DLL caller - some return codes are not that serious.

> I have two questions on this.

> 1.  Should I define an exception class for every return code which needs
to
> be raised?  Bearing in mind the large number of possible excepions which
> could be raised, is it better/possible to define a single Exception class
> for my DLL and have the caller read a property to determine the code.

> 2. How religious should I be about returning all codes this way.  In other
> words should I use Subs and assume success unless an exception occurrs, or
> is it acceptable to pass information back via function return codes for
> situations which do not represent critical failure.

> Any comments gratefully accepted.

> Mart



Tue, 20 Sep 2005 15:34:25 GMT  
 Exception Handling - the pragmatics
I concur with the other people that have responded. If you
want more information on this topic, Jeffrey Richter has
done alot of work in this area and has some great
recommendations. You can search whether he has any
articles on the Web or pick up one of his books.

Good luck!

Quote:
>-----Original Message-----
>I have a .Net DLL which needs to pass back to a caller
one of a number of
>possible result codes, for each of its methods called.

>Currently I am passing these back via the Return

statement.  Some of the
Quote:
>return values are represent serious problems and should
probably be raised
>as exceptions to the DLL caller - some return codes are
not that serious.

>I have two questions on this.

>1.  Should I define an exception class for every return
code which needs to
>be raised?  Bearing in mind the large number of possible
excepions which
>could be raised, is it better/possible to define a single
Exception class
>for my DLL and have the caller read a property to
determine the code.

>2. How religious should I be about returning all codes
this way.  In other
>words should I use Subs and assume success unless an

exception occurrs, or

- Show quoted text -

Quote:
>is it acceptable to pass information back via function
return codes for
>situations which do not represent critical failure.

>Any comments gratefully accepted.

>Mart

>.



Wed, 21 Sep 2005 00:50:17 GMT  
 Exception Handling - the pragmatics
One thing to bear in mind is that the design for exceptions in .NET was
based on the idea that they are only raised in exceptional circumstances
(and in those same circumstance exceptions would be used almost universally
as the signaling mechanism) and the performance tradeoffs were made
accordingly. So the perf cost of using an exception handler is almost
negligible whereas the cost of raising an exception is much higher (involves
stack walking).

You may not have performance concerns in your application, however, and
there is certainly a degree of gray area as to what constitutes an
exceptional failure, so your mileage may vary.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


Quote:
> I have a .Net DLL which needs to pass back to a caller one of a number of
> possible result codes, for each of its methods called.

> Currently I am passing these back via the Return statement.  Some of the
> return values are represent serious problems and should probably be raised
> as exceptions to the DLL caller - some return codes are not that serious.

> I have two questions on this.

> 1.  Should I define an exception class for every return code which needs
to
> be raised?  Bearing in mind the large number of possible excepions which
> could be raised, is it better/possible to define a single Exception class
> for my DLL and have the caller read a property to determine the code.

> 2. How religious should I be about returning all codes this way.  In other
> words should I use Subs and assume success unless an exception occurrs, or
> is it acceptable to pass information back via function return codes for
> situations which do not represent critical failure.

> Any comments gratefully accepted.

> Mart



Wed, 21 Sep 2005 08:54:41 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Exception Handling

2. Exception Handling

3. Application has generated an exception that could not be handled

4. In this case, what's the difference between CSharp and VB.NET Exception Handling

5. application has generated an exception that could not be handled

6. Best Practice for Exception Handling?

7. Exception Handling Help

8. Centralized exception handling

9. Exception handling MyClass.Name ?

10. Severe bug in Exception handling

11. Global Exception Handling

12. Applicationwide exception handling??

 

 
Powered by phpBB® Forum Software