Hi Michal, On Mon, 2011-04-04 at 16:02 +0200, [email protected] wrote: > This set of patches will add 'better' error/exceptions reporting. I tried to > make this > thing very simple and avoid voodoo we had in 'catched_exceptions' list. > > No you can use simple DSL (like features) to catching and describing > exceptions from > our beloved 'safely' blocks. > > Example usage: > > exceptions do > > on /AuthFailure/ do > status 401 # Authentication failed... > end > > on /No offering found/ do > status 400 # Wrong combination of hardware_profile / image > end > > on /CloudServers::Exception::(\w+)/ do > status 502 # Provider error > end > > on /Error/ > status 500 > message "Hello, this is a nice message to client." > exception CustomException > end > > end > > Let me know what do you think. All ideas how to improve it are welcome.
I still find this overengineered, and it doesn't address the main shortcoming of the current error handling scheme: that it's not possible to dispatch on criteria that seem more reliable than matching on specific words in the error message. For example, AWS only throws AwsError, but the HTTP status code in the exception is useful in some situations to cleanly and reliably generate the appropriate response; for example to handle authentication failures, you can check whether the AwsError has a status of 401. Having the DSL is nice, but I'd prefer a more flexible way to handle all that even if it requires more manual work; to me something like Rails' rescue_from is as far as I'd want to take this. David
