On Apr 5, 2011, at 1:49 AM, David Lutterkort wrote:

> 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.

This DSL is not supposed to work in way that it only sticks to error messages
(exception messages). You can also match exception class like:

/CloudServers::Exception::(\w+)/

Or you can combine them.

> 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.

I think this error code is 'rethrowned' from Net::HTTP class and it's available
in message. So we can do: '/AwsError.*401.*/' to achieve same effect.

> 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.

I though that rescue_from helper works just with classes, like:

rescue_from NoMethodError, :with => :show_error

In some cases this can be not applicable to our code, because some gems throwing
errors as part of Exception message (AwsError).

From AwsError you can get both 401 code with message and also 
InvalidAPICredentials
in case you enter wrong credentials.

I can easily add 'class' matching to this DSL and it will work in same way as 
rescue_from:

on NoMethodError do
  status xxx
  render :no_method_error
end

  -- Michal

------------------------------------------------------
Michal Fojtik, [email protected]
Deltacloud API: http://deltacloud.org

Reply via email to