Handling collections of errors 1

[MasterRacker]

thread678-1054016 ended by discussing returning an error collection instead of throwing exceptions. If I have a validation method that returns an object, even if there are no errors, I have to look into the object for a "no error" condition.

I'm thinking about having a validation method that returns a boolean, with false triggering the examination of the error collection. In this arrangement, what's the best way of passing the error collection? The two options I can think of are A) pass an error collection by reference to the validation method to be populated or B) making the error collection part of the object itself.

I can see pros/cons to each method. What's the more generally accepted thinking? Is there a third way that brain death is blinding me to? Is the whole thing a crock and should I only return the error collection directly?

[sub]Jeff
[purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day

I was not born cynical - I earned my cynicism through careful observation of the world around me.[/sub]

 

[stevexff]

If you use an error collection (or an object to hold it plus a boolean) you still have the same problem - you have a responsibility to check it after the call. Exceptions are better because you can't miss them. But as chiph notes in the other post, it's not a good idea to use them across layer boundaries.

There isn't much difference between checking that Errors.Count()is zero, or checking the boolean, so don't agonise over the choice (I'd probably go for the former - it's simpler).

If you are using .NET you may be able to code an FxCop rule to verify that you do check properly after each call, which would at least give you some confidence in the code quality.

 

[VolkerStamme]

If you're using C++ or C# you could overload your equals operator to allow your object to be compared to a boolean value. That's what I'm currently doing and would love to hear a second opinion on that. Allows you function calls like this

if ((! obj = MyFunc()))
  // obj.Errorcode tells you more

Volker/

 

[MasterRacker]

I'm using C#. Being fairly new to OO I'm still spending a lot of time trying to determine "best practices".

I guess I'm comparing

if (!object.IsValid())
{
  foreach (err in object.errors)
    Display(err);
}

and

ErrCollection err;
ErrItem e;
if (!object.IsValid(ref err))
{
  foreach (e in err)
    Display(e);
}

versus throwing exceptions versus some other method.

I'm doing a fairly vanilla process of filling a few different objects from forms and performing type, range and business rules checks before passing them to the DAL to be saved/updated in the DB.

[sub]Jeff
[purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day

I was not born cynical - I earned my cynicism through careful observation of the world around me.[/sub]

 

[Polu]

VolkerStamme: Overloadig the equal operator is going to be a nigthmare for a poor maintenance programmer in 2007. Please, flood your code with remmarks about this!

 

[chiph]

I too would say not to overload the equality operator unless everyone involved knows you're doing it, and you've commented the heck out of it. In .net, it's probably better to implement the IComparable interface.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[MasterRacker]

I don't think AI would like the idea of any kind of "equality" check working between dissimilar data types either. Might be a nice coding trick, but doesn't make logical "sense".

Any further comments on my original question about keeping the erors collection external to the object being checked vs. making it part of the object? Any gotchas to either method?

[sub]Jeff
[purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day

I was not born cynical - I earned my cynicism through careful observation of the world around me.[/sub]

 

[chiph]

Oh, you want the *original* question answered??
lol

I like your first method, with an encapsulated errors collection.

Some refinements:
I would create an interface (IErrorAnnouncer or something like that) that would be implemented by your objects. That way you'd be assured that your objects had one, and can address it via the interface if you chose to.

Your errors collection could be a list of various Exception types (you can create an exception without necessarily throwing it), or maybe a custom class which describes the error. I kindof like the idea of a custom class as it lets you be more descriptive, and you can always add a method that returns an exception if you feel a need to throw one at a later time.

public enum GroovyErrorEnum
{
   IsRequired,
   TooLong,
   TooShort,
   OverMax,
   UnderMin,
   FailedRegExValidation
}

public class MyGroovyError
{
   public string Msg;
   public string Location;
   public GroovyErrorEnum TypeOfError;

   public Exception ConvertToException()
   {
      return new Exception(msg);
   }
}

Chip H.

____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[MasterRacker]

Dude, you're making me feel like I know what I'm doing. ;-)

The enum and the 3 members in the error are exactly what I was doing. Your enum is a little more detailed than I had (gives me some ideas.)

One enhancement I thought of is to use canned messages based on the type, with the option of overriding the canned message with a custom one through a second constructor.

Sounds like I'm climbing the right mountain anyway. Thanks.

[sub]Jeff
[purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day

I was not born cynical - I earned my cynicism through careful observation of the world around me.[/sub]

 

[chiph]

Arrrrg, blast them with a canonnade! That'll teach them to hoist their mainsail in port!

Chip H.
(sorry -- just read your sig)
;-)


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[VolkerStamme]

Sorry for the little diversion but it seems we have at least similar problems.
As for commenting, I'm normally quite good in that, especially because it's likely to be me who's got to read this stuff in 2007 ;-). Thanks everyone, appreciate your input!!
Volker/

 

[MasterRacker]

Ahoy - someone actually read me sig, arghhh... [LOL]

Volker, I wouldn't do it the way you are, but I agree with everyone else. Especially if you're doing something out of the ordinary, comment the heck out of it.

(Years ago, I used to look at code I'd written a couple of years previously and wonder if I was high when I wrote it... [LOL])

[sub]Jeff
[purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day

I was not born cynical - I earned my cynicism through careful observation of the world around me.[/sub]

 

[VolkerStamme]

Yeah, know what your talking about The idea was just to have only one line of code as long as the function succeeds. I guess that type of lazyness won't pay..

Volker/

 

[BobRodes]

As for the original question: one of my favorite coding headaches is the fact that errors are handled in multiple ways in a given application. Sometimes it's hard not to do, for reasons already well taken up here. However, I've often wondered whether a good solution to error handling would be for all of the objects in an application to have a reference to the same error object, and catch every exception thrown and pass it to a method on that object, which could then handle errors in whatever way we liked. This would provide consistency and loose coupling at the same time.

Of course, I've never done this--it's hard enough to get people to pay for documentation....

Bob

 

[stevexff]

The main problem I have with this suggestion is that it doesn't take error context into account. While we could all probably agree that not being able to connect to the DBMS is a fairly crucial error, other errors may be OK in context. For example, suppose I'm looking for a customer address and don't find it. If the context is a call centre application, I might prompt the user to ask the customer for one, and enter it. I can just handle the 'error' locally. If I'm printing delivery labels for a shipment that's sitting on the loading dock, then it's an error I need to know about. A centralised error handler class can't know the context, so all it can do is maybe log the error.

Perhaps a compromise solution is better - handle the error locally, but pass it to a standard error reporting class, perhaps with a severity indicator set by the application. This could then log it, email a notification, or page support (or combinations of all three) depending on the severity. Or it could just hook into one of the proprietary data centre management tools like Tivoli, and let it do the rest.

 

[BobRodes]

Yeah, maybe that is better, but I don't see why a centralized error handler can't know context. Why can't you pass context to the handler?

Bob

 

[timw]

Maybe the centralized error handler could use callbacks for those special cases. You hand the handler a specific implementation of an interface through which it makes a call to do any stuff specific to the error context.

Could even have a library of such implementations, accessed via a Class Factory.

Not sure if this is overkill ... has anybody ever taken this approach?

Tim
---------------------------
"Your morbid fear of losing,
destroys the lives you're using." - Ozzy