DOC: Update tutorial on error handling

Summary

The error handling has been updated in the tutorial (see #52 (closed)). Also, #49 (closed) has been fixed on the way.

Focus

src/doc/tutorials/erros.rst

Test Environment

make doc on top level and look at build/doc/html/tutorials/errors.html.

Check List for the Author

Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab comments for the reviewer. They should guide the reviewer through the changes, explain your changes and also point out open questions. For further good practices have a look at our review guidelines

• All automated tests pass
• Reference related Issues
• Up-to-date CHANGELOG.md
• Annotations in code (Gitlab comments)
  • Intent of new code
  • Problems with old code
  • Why this implementation?

Check List for the Reviewer

• I understand the intent of this MR
• All automated tests pass
• Up-to-date CHANGELOG.md
• The test environment setup works and the intended behavior is reproducible in the test environment
• In-code documentation and comments are up-to-date.
• Check: Are there spezifications? Are they satisfied?

For further good practices have a look at our review guidelines.

src/doc/tutorials/errors.rst

@@ -2,13 +2,13 @@
 Error Handling
 ==============
 
-In case of erroneus transactions, connection problems and a lot of
+In case of erroneous transactions, connection problems and a lot of
 other cases, PyCaosDB may raise specific errors in order to pinpoint
-the problem as precisly as possible. Some of these errors a
-representations of errors in the CaosDB server, otheres stem from
+the problem as precisely as possible. Some of these errors a
+representations of errors in the CaosDB server, others stem from
 problems that occurred on the client side.
 
-The errors and exceptions are ordered hierarichally form the most
+The errors and exceptions are ordered hierarchically form the most
 general exceptions to specific transaction or connection problems. The
 most important error types and the hierarchy will be explained in the
 following. For more information on specific error types, see also the
@@ -40,14 +40,23 @@ Every transaction (calling ``insert``, ``update``, ``retrieve``, or
 indicate, for instance, that an entity does not exist or that you need
 to specify a data type for your property and much more. If and only if
 one or more errors occur during a transaction a ``TransactionError``
-will be raised by the transaction method. The ``TransactionError`` class
-is a container for all errors which occur during a transaction. It can
-help you to find the crucial problems with your transaction by two
-important methods: \* ``get_errors()`` which returns a list of instances
-of ``EntityError``. \* ``get_entities()`` which returns a list of
-entities in the transaction container which are erroneous.
-
-Additionally, ``print(transaction_error`` prints a tree-like
+will be raised by the transaction method. The ``TransactionError``
+class is a container for all errors which occur during a
+transaction. It usually contains one or more :ref:`entity
+errors<EntityError>` which you can inspect in order to learn why the
+transaction failed. For this inspection, there are some helpful
+attributes and methods provided by the ``TransactionError``:
+
+* ``entities``: a set of all entities that caused at least one error
+  in this transaction
+
+* ``errors``: a set of all ``EntityError`` objects that occurred during
+  the transaction.
+
+* ``has_error(error_t)``: Check whether an error of type ``error_t``
+  occurred during the transaction.
+
+Additionally, ``print(transaction_error)`` prints a tree-like
 representation of all errors regarding the transaction in question.
 
 EntityError