Handling exception in calling a external api










0















I'm calling Udemy external api to build a simple REST service for experimental purpose.



https://www.udemy.com/developers/affiliate/



Here is my get_all() courses method.



class Courses(object):
"""
Handles all requests related to courses.
ie; gets the courses-list, courses-detail, coursesreviews-list
"""

def __init__(self, api):
self.api = api
logger.debug("courses initialized")

def get_all(self):
page = 1
per_page = 20

while True:
res = self._get_courses(page, per_page)
if not res['results']:
break

try:
for one in res['results']:
yield one
except Exception as e: -->>>handling exception
print(e)
break

page += 1

def _get_courses_detail(self, page, per_page):
resource = "courses"
params = 'page': page, 'per_page': per_page,
# 'fields[course]': '@all'


res = self.api.get(resource, params)
return res


Now, is it reasonable to handle a exception(in get_all() method) assuming that there could some error in the returning data of the api?



Or handling the exception(in get_all) is not needed here and it should be handled by the calling function?



Most of the open source projects that I see don't handle this exception.










share|improve this question


























    0















    I'm calling Udemy external api to build a simple REST service for experimental purpose.



    https://www.udemy.com/developers/affiliate/



    Here is my get_all() courses method.



    class Courses(object):
    """
    Handles all requests related to courses.
    ie; gets the courses-list, courses-detail, coursesreviews-list
    """

    def __init__(self, api):
    self.api = api
    logger.debug("courses initialized")

    def get_all(self):
    page = 1
    per_page = 20

    while True:
    res = self._get_courses(page, per_page)
    if not res['results']:
    break

    try:
    for one in res['results']:
    yield one
    except Exception as e: -->>>handling exception
    print(e)
    break

    page += 1

    def _get_courses_detail(self, page, per_page):
    resource = "courses"
    params = 'page': page, 'per_page': per_page,
    # 'fields[course]': '@all'


    res = self.api.get(resource, params)
    return res


    Now, is it reasonable to handle a exception(in get_all() method) assuming that there could some error in the returning data of the api?



    Or handling the exception(in get_all) is not needed here and it should be handled by the calling function?



    Most of the open source projects that I see don't handle this exception.










    share|improve this question
























      0












      0








      0








      I'm calling Udemy external api to build a simple REST service for experimental purpose.



      https://www.udemy.com/developers/affiliate/



      Here is my get_all() courses method.



      class Courses(object):
      """
      Handles all requests related to courses.
      ie; gets the courses-list, courses-detail, coursesreviews-list
      """

      def __init__(self, api):
      self.api = api
      logger.debug("courses initialized")

      def get_all(self):
      page = 1
      per_page = 20

      while True:
      res = self._get_courses(page, per_page)
      if not res['results']:
      break

      try:
      for one in res['results']:
      yield one
      except Exception as e: -->>>handling exception
      print(e)
      break

      page += 1

      def _get_courses_detail(self, page, per_page):
      resource = "courses"
      params = 'page': page, 'per_page': per_page,
      # 'fields[course]': '@all'


      res = self.api.get(resource, params)
      return res


      Now, is it reasonable to handle a exception(in get_all() method) assuming that there could some error in the returning data of the api?



      Or handling the exception(in get_all) is not needed here and it should be handled by the calling function?



      Most of the open source projects that I see don't handle this exception.










      share|improve this question














      I'm calling Udemy external api to build a simple REST service for experimental purpose.



      https://www.udemy.com/developers/affiliate/



      Here is my get_all() courses method.



      class Courses(object):
      """
      Handles all requests related to courses.
      ie; gets the courses-list, courses-detail, coursesreviews-list
      """

      def __init__(self, api):
      self.api = api
      logger.debug("courses initialized")

      def get_all(self):
      page = 1
      per_page = 20

      while True:
      res = self._get_courses(page, per_page)
      if not res['results']:
      break

      try:
      for one in res['results']:
      yield one
      except Exception as e: -->>>handling exception
      print(e)
      break

      page += 1

      def _get_courses_detail(self, page, per_page):
      resource = "courses"
      params = 'page': page, 'per_page': per_page,
      # 'fields[course]': '@all'


      res = self.api.get(resource, params)
      return res


      Now, is it reasonable to handle a exception(in get_all() method) assuming that there could some error in the returning data of the api?



      Or handling the exception(in get_all) is not needed here and it should be handled by the calling function?



      Most of the open source projects that I see don't handle this exception.







      python rest django-rest-framework






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 12 '18 at 12:50









      user1050619user1050619

      6,10135129234




      6,10135129234






















          1 Answer
          1






          active

          oldest

          votes


















          0














          I'm sharing the opinion in this answer. So catch the exception as soon as possible and rethrow it if needed to the next layer.




          With practice and experience with your code base it becomes quite easy to judge when to add additional context to errors, and where it's most sensible to actually, finally handle the errors.



          Catch → Rethrow



          Do this where you can usefully add more information that would save a developer having to work through all the layers to understand the problem.



          Catch → Handle



          Do this where you can make final decisions on what is an appropriate, but different execution flow through the software.



          Catch → Error Return







          share|improve this answer






















            Your Answer






            StackExchange.ifUsing("editor", function ()
            StackExchange.using("externalEditor", function ()
            StackExchange.using("snippets", function ()
            StackExchange.snippets.init();
            );
            );
            , "code-snippets");

            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "1"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53262572%2fhandling-exception-in-calling-a-external-api%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            0














            I'm sharing the opinion in this answer. So catch the exception as soon as possible and rethrow it if needed to the next layer.




            With practice and experience with your code base it becomes quite easy to judge when to add additional context to errors, and where it's most sensible to actually, finally handle the errors.



            Catch → Rethrow



            Do this where you can usefully add more information that would save a developer having to work through all the layers to understand the problem.



            Catch → Handle



            Do this where you can make final decisions on what is an appropriate, but different execution flow through the software.



            Catch → Error Return







            share|improve this answer



























              0














              I'm sharing the opinion in this answer. So catch the exception as soon as possible and rethrow it if needed to the next layer.




              With practice and experience with your code base it becomes quite easy to judge when to add additional context to errors, and where it's most sensible to actually, finally handle the errors.



              Catch → Rethrow



              Do this where you can usefully add more information that would save a developer having to work through all the layers to understand the problem.



              Catch → Handle



              Do this where you can make final decisions on what is an appropriate, but different execution flow through the software.



              Catch → Error Return







              share|improve this answer

























                0












                0








                0







                I'm sharing the opinion in this answer. So catch the exception as soon as possible and rethrow it if needed to the next layer.




                With practice and experience with your code base it becomes quite easy to judge when to add additional context to errors, and where it's most sensible to actually, finally handle the errors.



                Catch → Rethrow



                Do this where you can usefully add more information that would save a developer having to work through all the layers to understand the problem.



                Catch → Handle



                Do this where you can make final decisions on what is an appropriate, but different execution flow through the software.



                Catch → Error Return







                share|improve this answer













                I'm sharing the opinion in this answer. So catch the exception as soon as possible and rethrow it if needed to the next layer.




                With practice and experience with your code base it becomes quite easy to judge when to add additional context to errors, and where it's most sensible to actually, finally handle the errors.



                Catch → Rethrow



                Do this where you can usefully add more information that would save a developer having to work through all the layers to understand the problem.



                Catch → Handle



                Do this where you can make final decisions on what is an appropriate, but different execution flow through the software.



                Catch → Error Return








                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 12 '18 at 13:00









                zyprozypro

                6312828




                6312828



























                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53262572%2fhandling-exception-in-calling-a-external-api%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Use pre created SQLite database for Android project in kotlin

                    Darth Vader #20

                    Ondo