[Eis-devel] What to do with errors...
Status: Pre-Alpha
Brought to you by:
baslijnse
|
From: Bas L. <ba...@ba...> - 2007-08-28 12:27:21
|
Hi All, I have been working on the servermanager application and got the feeling that the way user errors are currently handled in EIS is not the best way to go. So please think with me, and let me know how you think that errors should be handled. My first question is whether a service should stop immediately after an error is found. EIS1.5 services do not and try to find all errors and return them as an array. The other option is to stop when the first error is found and return only one. One error is more simple than finding all errors and will provide one specific reason why a process is cancelled with a single error message. An array of errors can be helpfull when many things are wrong that can be fixed by the user before resubmitting. The second question is at what point translation of error messages should be handled. One option is to do translation in the service when an error is detected. This is easy because all the information for construction is directly available but also means that when a service is invoked it will have to be language aware. This is a bit awkward when calling services via xml-rpc for example. Another option is to leave translation of error messages to elements or rpc clients. This is a more presentation independent solution but does mean that the client will need to be able to translate string identifiers to text and that information that has to be replaced in the messages will have to be provided as well. For example, a message like "The username 'johndoe' is already in use" should be constructed from a code "e.username.taken" and the replacement "johndoe". This would mean that error objects become more complex than just numbers or strings. My current preference would be to stop when the first error is found and to do translation in elements or rpc-clients. What are your thoughts? greetz, Bas |