0

I am trying to abstract the elasticsearch python client.

I have a method index document

def index(self, body, id=None):
        """
        Inserts one document into elasticsaerch.
        If id is None then it will autogenerate the id.

            :param self:
            :param body:
            :param id=None:
        """
        try:
            response = self.__client.index(
                self.__index, self.__doc_type, body, id)
        except Exception as e:
            print str(e)
            print traceback.print_exc()

Elasticsearch returns a response like :

{u'_type': u'category', u'_shards': {u'successful': 1, u'failed': 0, u'total': 2}, u'_index': u'catalog-2017-12-07', u'_version': 1, u'created': True, u'result': u'created', u'_id': u'AWA7N75WNaGquN-GGszi'}

I put a try catch inside my Facade class to handle if document cannot be indexed for any reason.

I am confused about

1 - log errors in this class itself or inform my client class about this by re-throwing the exception

2 - simply return True/False to client

1 Answers1

6

You must always inform your caller if your method fails for some reason. Otherwise, the caller will "happily" continue and run into strange follow-up errors.

I'd strongly recommend to do that with an exception (either the original one or one created by you). Returning true/false was the old-fashioned style from times before exceptions were invented and often led to unreliable code as developers sometimes forgot to check for "false"...

If you throw your own exception, make sure that it contains every bit of information from the original one. You'll be grateful for that when you read your customer's log files.

Generally, you should not log exceptions at lower levels, but instead throw exceptions and rely on some top level to do the logging. Otherwise, you'll end up with the same exception logged multiple times at different application layers. But to tis rule, there are exceptions...

Ralf Kleberhoff
  • 5,891
  • 15
  • 19