The more I work with SF I find myself entering code testing the BO.Count > 0 to prevent errors like this:

I wonder if this type of error could be eliminated by the BO itself, instead of we having to keep testing all over for the BO.Count > 0?

I have not checked the BO source code but is there a reason why the BO gracefully does not take care of this instead of throwing an error?

This is somewhat like asking for an airplane that is impervious to weather and crashing....it isn't possible.  It is reasonable to test for this within your application for empty records within certain conditions...and this isn't unique to a BO...this is a standard .NET object model and collection implemenation.  You would have the same problem dealing with any type of collection in this reagrd.

We did make a change the other day to add the schema and table name to the message.  but let's say for a moment that we were going to do something.  Let's take the scenario where you request something from the BO (i.e. reference a strong-typed field property), at this point one of the two things would have to happen:

1. The BO in question would have to either add a new record or retrieve a record from the database.  Iin either case, how would the framework intrinsically know what to do...it wouldn't.
2. Return a default value to prevent the error (i.e. return empty string for string, etc.).  This would be EXTREMELY bad in that you actually have a bug in your application and woudl then proceed to chase your tail when something wasn't saved to the database...I can even predict the subject of the forum post it would generate, "BO not saving record..."...which would then turn into, a log or exception should be thrown so that the developer knows what to do.

So in short, no, the framework should not prevent the error, but do exactly what it does, let you know that you have an issue within your code that needs to be addressed.

No, refer to the above answer.

While I do sort of understand your reasons to report the error to the user, my request is more on the part of when using a BO field property and this BO has not record, then we will get an error and force us to do the BO.Count check, which in my case it happens many times when using a related BOs with several listview or comboboxes.

I was under the impression that when using a BO field property and there is not record i the BO, that it should simply return the empty value of that property and avoid having to do all the BO.Count checking.  Obviously, this is .NET and I am still learning so guess will have to get used to do the BO.Count checking all the time.

P.S.

I may be wrong, but while testing all the .NET frameworks in the market for me to use, I believe one of them will just return the equivalent of the default empty value of the property being used, but again, I can not be sure, just thought it could be done.

No, it is designed and intended this way.

I answered this point above...we tested this on a framework prior to writing SF...and this is a really bad standard on their part!  If we just returned a default value, then you could have a bug and not know about it.  For example, if a value is return for a string (empty string), and you thought a record (as the end-user would at this point) was available and saved, then it would appear that you have data loss, when in fact you don't...you have a bug.

We can discuss this more in class, but this is something that we will not change which says a lot because we are always open for discussion in how to improve the framework.  But this would put all of our users at risk which it is our responsibility as developers of a framework to instill best practices and protect our users.  So it is as it was intended and should be to best protect our users.  If you don't like this logic, then overwrite this logic in your base BO class....however, I would strongly advise against this!!!