On 19/04/2008, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> wrote:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> It was noted on IRC that the search engine has no way of telling the client "hey I screwed up" after StartSearch(s) has been invoked. The reasons for this could be many - OOM, non-fatal bug, full moon, etc. Currently the only real solution is to emit SearchDone and let the client wonder why it only received 0 hits. There are two alternatives : 1) Introduce a new signal SearchFailed(s: search_handle, i: error_code, s: message). This will be the  API compatible solution 2) Add a new value to the SearchDone signal, changing signature to SearchDone (s: search_handle, i: exit_code, s: message). This will break API however I hate 2) because it (doh) it breaks API. I love 2) because it will fit much better in to my control flow logic. I am more or less indifferent on 1) - it is not very clean IMHO, but it is API stable. Status quo could be acceptable to me, but I think it could be a good idea to make better room for handling of bugs. After all Xesam is an all new technology we are pusing in. 2 gets my vote. I am very much willing to reconsider if people are massively annoyed by this (small) API change.</blockquote><div> I am having second thoughts on this. Since a normal SearchDone does not necessarily mean that the search has stopped running in case of a live session. On the other hand a SearchFailed signal (or what ever we call it) will probably always mean that search is dead (the question is whether the client needs to call CloseSearch on it is open then). So from +1 on 2) I have swung my mood to "indecisive". If I don't get feedback on this we will go for the API stable solution (ie adding SearchFailed). Cheers, Mikkel </div></div>