>Sounds like BatFink is pretty well thought out! >
Thank you! Glad to hear you think so. >Designing a good exception handling model into a framework is >key because it affects so much of how developers will do error >/ exception handling. One thing folks should bear in mind is >that exceptions are really intended for 'exceptional' >situations, not for 'expected' >errors. In other words, your data integrity exception is a good example >- because the system is designed to create a unique email and >have a single verification action. Things like hitting the end >of a file or the end of a list are 'expected' errors and >shouldn't warrant an exception. User input validation is a >somewhat grey area because you can 'expect' users to enter >invalid data but validation of hidden fields might lead to >'exceptional' errors. There are also user input scenarios >where you can't easily validate the data fully and only by >attempting to work on it within the model can you completely >validate it - which also might create 'exceptional' errors. Yes, it's a bit tricky. Having spent the last couple hours puzzling over it, I've decided that the current approach of throwing exceptions of type validation just isn't good enough. I'm currently leaning towards creating a validator service in the model that allows you to pass in form data and returns a validation object/structure that contains a key telling you if the validation succeeded as a whole and a struct containing message and errorcode for each field that failed. The presenter can then re-route back to the original form and the view layer can decide whether to use the message from the model or use a custom one based on the error code. The validation service can be called by the form action method in the presenter layer before passing the data to the model to update the database. The question is whether or not the validation service should check whether say a username already exists in the database, or only if the username submitted has a valid length and characters. If it checks for data integrity in the database you add some overhead to the validation service and you have to trust in the database update methods that the validation has been done correctly. If it doesn't check data integrity, you still have to somehow get that 'expected' problem back to the action method preferably without raising an exception. There are also edge conditions where two users simultaneously sign up with the same username and they both pass the validation check, but only one of them gets added to the database. The other gets a data integrity error. I think I can live with the edge conditions and I'm thinking that checking for existing values in the database is probably the best way to go, but I'm open to suggestions if anyone has a better idea. Spike --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
