Re: afterthought about the API

+1 for the null-value. For implementations in languages like javascript,
having the need to handle exceptions can be a real burden for widespread
adoption of the API.

Felix

2009/10/20 Pierre-Antoine <pierre-antoine.champin@liris.cnrs.fr>

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