.NET Questions (CLOSED)

Questions and Answers on any aspect of .NET. Now closed.

This discussion group is now closed.

Have a question about .NET development? Try stackoverflow.com, a worldwide community of great developers asking and answering questions 24 hours a day.

The archives of .NET Questions contain years of Q&A. Even older .NET Questions are still online, too.

Getting valuable information back

I have a class method called Save(), which saves the object's data to a database.  How do you typically sign the method, does it return a boolean? void?

Should save be Void and throw and exception if it cannot Save?  Or should it be a boolean indicating the success of the save?

If I have defined: bool Save().

I'm using this in another piece of code and when the value is false I want to write a message to the Trace inidicating that the Save failed and why it failed.  However when I get a boolean result back I don't have another means to get information back from the method, I know it failed, but what went wrong?  How can I programming the class give more information to the user in certain situations?  Another programmer I've seen has a "ref string" parameter on everything to put messages into.  Is this a good way?  Someone have smoething better?

Thanks,

-T
Tim Send private email
Tuesday, January 09, 2007
 
 
If the Save should normally work (i.e., it doesn't validate some stuff then save), then it should throw an exception if something exceptional happens, e.g. the database is down.

If it checks to see if a save is valid and then saves, you can a few options:

- throw an exception (some feel this is an abuse of exceptions for something that is not really exceptional;, e.g. invalid user input)

- return a string that's an error message if it failed and null if it worked (some feel this is a poor practise to use null to have a special meaning)

- return a boolean and use a ref string to return the message if it failed (some feel this is a rather awkward way to return information via two mechanisms)

- return a Result object that encapsulates the boolean and the message and any other relevant information (this is currently my favourite, but I've changed my mind several times over the past few years!)
Mike S Send private email
Tuesday, January 09, 2007
 
 
I agree with Mike S, if you are only trapping for things like database errors, then throw an exception and letting the calling code handle it. In cases like this I would put my logging right in the Read function, that way if you call it from 10 different places you don't have to worry about logging in each. If you write Exception.ToString to your log you will not only get the error message, but the full stack trace so you know what the calling routine was.

Dan
Dan Boris Send private email
Tuesday, January 09, 2007
 
 
Throw an exception.  If the Save method can't do what it was asked to do (save the object) an exception is how it tells the client code.  You can create a custom exception type to hold as much detailed information as you need to solve the problem.

If you don't want to throw exceptions for simple validation errors, create a Validate method that clients can use before attempting to save. 

If a callee can't live up to its implicit contract, it should throw an exception to the caller to notify it of that fact.  The whole "the situation must be truly exceptional" argument is malarkey.  Jefferey Richter has an excellent chapter on exceptions in his CLR via C# book that covers this.  It should be on the required reading list for all .NET developers.
Jake
Tuesday, January 09, 2007
 
 
I use the "thrown an exception method" too.  Too often I have seen the 'bool Save()' return value get stuffed into a temp variable and never handled.
A Guy
Tuesday, January 09, 2007
 
 
I usually have 2 Save methods to deal with this:

1) SaveThrow: If the save failed, this throws a custom exception containing the nested real exception. If the save succeeded, returns nothing (void).

2) SaveNoThrow: always returns a custom Result type - if the save failed, this custom type also has a property containing the real exception.

In this way, the client code has a choice on a call-by-call basis.
Mark Pearce Send private email
Wednesday, January 10, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz