Re: [mawg]Error handling in the API (was: afterthought about the API)

Hi Chris,

I'd refrain from anything that can interrupt a program flow. Rather,
there should be a error code returned (that can be ignored) and then
if needed that error code can be analysed and evasive action taken.
Throwing exceptions is a bad design for such an interface.

BTW: do we have experienced programmers with library API design
experience on the list? If not, somebody from the jquery community or
similar could be a great addition at this stage of the process!

Cheers,
Silvia.

On Tue, Nov 17, 2009 at 7:46 PM, Chris Poppe <Chris.Poppe@ugent.be> wrote:
> Dear all,
>
> I wanted to bring this email back under the attention of the group, since we are now getting further with the API. Pierre-Antoine proposed to not use exceptions and to include a method to request a diagnosis when something went wrong. This was also added in the Web IDL description of the generic GET method that I sent yesterday.
>
> It would be very valuable if Silvia (or Doug, don't know if he follows this mailing list) could comment on this topic to state what would be the best way to deal with it.
>
> Kind regards,
> Chris
>
> -----Original Message-----
> From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Pierre-Antoine
> Sent: dinsdag 20 oktober 2009 15:04
> To: public-media-annotation@w3.org
> Subject: afterthought about the API
>
> Hi all,
>
> last week, we discussed about return values; I asked why use exception
> rather than null values when no value is available.
>
> Chris's answer was that an exception can carry the *reason* why there
> was no value. I guess the rationale is that reasons could be sth like:
>  - property has no value in source
>  - property is not specified in source
>  - property is not supported by source format
>  - value of the property could not be converted to the return datatype
>  ...
>
> I think this argument makes sense: it is useful to know the reason why
> there is no value.
>
> However, I keep thinking that
>
>   c = md.creator;
>   if (c != null) {
>     ...
>   }
>
> is much easier to write and read than
>
>   try {
>     c = md.creator;
>     ...
>   }
>   catch (err) {
>     if (err.name != "NoValue") { throw err; }
>   }
>
> so I think (again) that for easing the simple cases, we should strick to
> a null value.
>
> I guess the NoValue.message feature could be replace by somethinh like a
> getDiagnoss() method retrieving the reason for the absence of value. For
> example :
>
>   c = md.creator;
>   if (c == null) {
>     alert(md.get_diagnosis("creator"));
>   } else {
>     ...
>   }
>
>
>   pa
>
>
>
>

Received on Tuesday, 17 November 2009 10:08:03 UTC