I am currently doing something similar to the following on every save() I do.

Select Case Me.Save

Case MicroFour.StrataFrame.Data.SaveUndoResult.AbortedWithBrokenRules

Throw New BrokenRulesException(Me.BrokenRules)

Case MicroFour.StrataFrame.Data.SaveUndoResult.FailedWithExceptions

Throw New ApplicationException("The save failed.")

End Select

I trap for broken rules and bubble them up with one custom exception class, and throw exceptions for the other results. Because of this I wind up with an ugly Case statement for every save. Is there any reason not to move this logic to the ErrorSaving event of the business object's themselves to centralize this or is this just the best way to do it?

Thanks!

Clay

I wanted to add a little more detail to what I am trying to accomplish.

When performing Save(True) operations on multiple business objects at one time and one of the Save operations fail, I want to rollback the transaction then throw a specific exceptin as described below.

1. When a save fails due to broken rules, I want to throw a custom exception containing these broken rules to the presentation layer (we are currently converting the broken rules collection to a JSON string and passing that string).
2. When a save failes due to any other reason, I want to rethrow that exception up the chain
3. When either of the above happen, I want to write either the exception or the broken rules to the application log. The idea is that our presentation tier validation should nearly eliminate broken rules from being written to the app log (I hope!).

I thought about overriding the Save() method and putting the logic there. I also thought about putting the logic in the Business Rules Checked event but I'm thinking that would miss straight out failures.

What I'm looking for is mostly an idea of what would be the best practice and maybe how others are doing this type of operation,. I hope this makes sense!

Clay

Another option would be to create the BoBase class and override Save().  Call MyBase.Save() and check the return value within your own Save() and check the select case there.  You could even show your form with the broken rules there if you don't mind taking that portion of the UI out of the UI...

This is what I've come up with...what do you think?

Public Overrides Function Save(ByVal b As Boolean) As MicroFour.StrataFrame.Data.SaveUndoResult

Dim r As MicroFour.StrataFrame.Data.SaveUndoResult

r = MyBase.Save(b)

If Not (r = MicroFour.StrataFrame.Data.SaveUndoResult.Success OrElse _

r = MicroFour.StrataFrame.Data.SaveUndoResult.Cancelled OrElse _

r = MicroFour.StrataFrame.Data.SaveUndoResult.CompletedWithExceptions) Then

Select Case r

Case MicroFour.StrataFrame.Data.SaveUndoResult.AbortedWithBrokenRules

Dim strJson As String = LitJson.JsonHelper.WriteJsonString(Me.BrokenRules)

Utility.SystemUtilities.ErrHandler.WriteEventLog(strJson, "", Diagnostics.EventLogEntryType.Error)

Throw New Exceptions.BrokenRulesException(strJson)

Case MicroFour.StrataFrame.Data.SaveUndoResult.FailedWithExceptions

Throw New ApplicationException()

End Select

End If

End Function

Is the ErrorSaving event the only place I can examine the exceptions that cause FailedWithExceptions?

I'm not tracking on this part...

I generally create my own base classes using your templates then inherit from those.

If an exception is encountered from within the save, then the exception will just be bubbled up if the ErrorSavingMode is FailOnError and the return value will be CompletedWithExceptions if the ErrorSavingMode is ContinueOnError.  If ContinueOnError is used, then yes, the ErrorSaving event will contain the exceptions thrown. 

So, the FailedWithExceptions is used for the SaveByForm() method, not the Save() method.  So, if you're going to be saving all of the business objects at once through the form's Save() method, then I you would want to override the SaveByForm() method and do the same thing (but I don't think that one is overridable, so if you're saving through the form's Save() method, then we might need to work out something different).

I was just saying that when you create a new business object from our template, it will inherit from BusinessLayer, so you will need to change it so that it inherits from your class, not BusinessLayer.  The base class that you create will be excactly like you mentioned... it's a basic business object (that itself will inherit from BusinessLayer).

The 2 Handler functions basically write to the event log and then rethrow a custom exception to the presentation layer.