From: Jon Baer <jonbaer@...>
Date: 2006-01-20T05:16:57+09:00
Subject: Re: rdoc, api + exceptions

I guess this stems from not having to "precompile" an app vs. only  
having the exception come up at runtime.

For example when using ActiveRecord for the first time I was unaware  
that a specific type of exception could occur based on a record not  
being located (which is obvious) but what type of exception I was  
expected to trap was not + only found during unit/web test.

<op>
It would be nice to have something equivalent to @throws in rdoc to  
highlight what might occur.
</op>

- Jon

On Jan 19, 2006, at 2:36 PM, Jim Weirich wrote:

> jon baer wrote:
>> Normally when developing an API you can express what exceptions may
>> occur when invoking a particular method ...
>>
>> public foobar() throws BadFooBarException
>>
>> In Ruby, it would seem to me that nearly ~everything~ can throw at
>> least one exception (or at least cause NameError), so Im wondering at
>> least how you would document that your method should be placed in a
>> begin/rescue/end block from a custom exception.
>
> I follow a simple rule when dealing with exceptions and it works  
> equally
> well in Java or Ruby.
>
> Every method has a purpose.  If a method is unable to achieve its
> purpose, then it must fail (and indicate failure via an exception).
>
> So when do you wrap a method in a begin/rescue clause?  When the  
> failure
> of a called method should not cause the failure of the calling method.
> Rescue the failure, attempt to fix it and continue.
>
> When you think of the problem in terms of success/failure, then the  
> type
> of failure is usually not important.  This means you don't (usually)
> have to worry about exactly which type of exception is being thrown  
> and
> making sure you capture each and every possible exception type (which
> creates quite fragile programs IMHO).
>
> --
> -- Jim Weirich
>
> -- 
> Posted via http://www.ruby-forum.com/.
>
>