anchor.diff:  
   - var rejected_promise = _docsFor == 'dart' ? 'propagated exception' : 'rejected promise';
   :marked
  +  데모 서비스에서는 콘솔에 에러를 남깁니다; 실제로는 더 잘할 것입니다.
  +
     In this demo service we log the error to the console; we would do better in real life.
  +
  +  또한 호출자가 적절한 에러 메시지를 사용자에게 보여 줄 수 있도록,
  +  거부 된(rejected) promise의 호출자에게 좀 더 사용자 친화적인 형태의 에러를 반환하기로 했습니다.
   
     We've also decided to return a user friendly form of the error to
     the caller in a !{rejected_promise} so that the caller can display a proper error message to the user.
  
positive.code: 
  .l-main-section
  :marked
    ## Heroes and HTTP
  
    Look at our current `HeroService` implementation
  
  +makeExcerpt('toh-4/ts/app/hero.service.ts (old getHeroes)', 'get-heroes')
  
  :marked
    We returned a !{_Promise} resolved with mock heroes.
    It may have seemed like overkill at the time, but we were anticipating the
    day when we fetched heroes with an HTTP client and we knew that would have to be an asynchronous operation.
  
    That day has arrived! Let's convert `getHeroes()` to use HTTP.
  
  +makeExcerpt('app/hero.service.ts (updated getHeroes and new class members)', 'getHeroes')
  
  :marked
    Our updated import statements are now:
  
  +makeExcerpt('app/hero.service.ts (updated imports)', 'imports')
  
  - var _h3id = `http-${_promise}`
  :marked
    Refresh the browser, and the hero data should be successfully loaded from the
    mock server.
  
    <h3 id="!{_h3id}">HTTP !{_Promise}</h3>
  
    We're still returning a !{_Promise} but we're creating it differently.
  
  block get-heroes-details
    :marked
      The Angular `http.get` returns an RxJS `Observable`.
      *Observables* are a powerful way to manage asynchronous data flows.
      We'll learn about [Observables](#observables) later in this chapter.
  
      For *now* we get back on familiar ground by immediately by
      converting that `Observable` to a `Promise` using the `toPromise` operator.
  
    +makeExcerpt('app/hero.service.ts', 'to-promise', '')
  
    :marked
      Unfortunately, the Angular `Observable` doesn't have a `toPromise` operator ...
      not out of the box.
      The Angular `Observable` is a bare-bones implementation.
  
      There are scores of operators like `toPromise` that extend `Observable` with useful capabilities.
      If we want those capabilities, we have to add the operators ourselves.
      That's as easy as importing them from the RxJS library like this:
  
negative.code:   +makeExcerpt('app/hero.service.ts', 'rxjs', '')
  
    :marked
      ### *then* 콜백에서 데이터 가져오기
      ### Extracting the data in the *then* callback
  
      *promise*의 `then` 콜백에서, 응답 데이터를 가져오기 위해 HTTP `Response`의 `json` 메소드를 호출합니다.
  
      In the *promise*'s `then` callback we call the `json` method of the HTTP `Response` to extract the
      data within the response.
    +makeExcerpt('app/hero.service.ts', 'to-data', '')
  
  :marked
    응답 JSON은 한개의 `data` 프로퍼티를 가지고 있습니다.
    `data` 프로퍼티는 호출자가 정말로 원하는 *히어로*의 !{_array}을 가지고 있습니다.
    그러므로 그 배열을 가져와서 결정(resolved)된 !{_Promise} 값으로 반환합니다.
  
    That response JSON has a single `data` property.
    The `data` property holds the !{_array} of *heroes* that the caller really wants.
    So we grab that !{_array} and return it as the resolved !{_Promise} value.
  
  .alert.is-important
    :marked
      서버에서 반환된 데이터의 모양에 주목하세요.
      이 특별한 *in-memory 웹 API* 예제는 `data` 프로퍼티를 가진 객체를 반환합니다.
      당신의 API는 다른 것을 반환할 수도 있습니다. *당신의 웹 API*에 맞춰 코드를 수정하세요.
  
      Pay close attention to the shape of the data returned by the server.
      This particular *in-memory web API* example happens to return an object with a `data` property.
      Your API might return something else. Adjust the code to match *your web API*.
  
  :marked
    호출자는 이러한 비밀을 알지 못합니다. 단지 이전에 했던 것처럼 *히어로*의 !{_Promise}를 받았을 뿐입니다.
    (샘플) 서버에서 히어로를 가져오는 것을 전혀 모르고 있습니다.
    HTTP 응답을 히어로로 변환하는데 필요한 우여곡절에 대해 아무것도 모릅니다.
    이것이 `HeroService`와 같은 서비스에 데이터 접근을 위임하는 목적이자 묘미입니다.
  
    The caller is unaware of these machinations. It receives a !{_Promise} of *heroes* just as it did before.
    It has no idea that we fetched the heroes from the (mock) server.
    It knows nothing of the twists and turns required to convert the HTTP response into heroes.
    Such is the beauty and purpose of delegating data access to a service like this `HeroService`.
  
    ### 에러 처리
    ### Error Handling
  
    `getHeroes`의 끝에서 서버 실패를 `catch`하고 그것을 에러 핸들러에 전달했습니다:
  
    At the end of `getHeroes()` we `catch` server failures and pass them to an error handler:
  
  +makeExcerpt('app/hero.service.ts', 'catch', '')
  
  :marked
    이것은 중요한 단계입니다!
    서버 실패는 우리가 제어할 수 없는 이유로 자주 발생하기 때문에 반드시 HTTP 실패를 고려해야 합니다.
  
    This is a critical step!
    We must anticipate HTTP failures as they happen frequently for reasons beyond our control.
  
  