Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fouten laten opborrelen #68

Open
claeyswo opened this issue Nov 18, 2016 · 6 comments
Open

Fouten laten opborrelen #68

claeyswo opened this issue Nov 18, 2016 · 6 comments

Comments

@claeyswo
Copy link
Member

https://github.com/OnroerendErfgoed/crabpy/blob/master/crabpy/gateway/capakey.py#L48

Als op dat punt een GatewayRuntimeException wordt gegenereerd wordt die later vervangen door een GatewayResourceNotFoundException. Op dat punt zijn we eigenlijk volledig kwijt wat de oorspronkelijke fout was. Ofwel de oorspronkelijke foutboodschap mee doorsturen naar boven of error logging voorzien bij de root exception.

@koenedaele
Copy link
Member

Als ik me goed herinner geeft CAPAKEY WS bij een niet bestaand perceel een runtime fout. Ik denk dat er geen verschil was tussen een niet bestaand perceel en een foute call. Zie #49 en OnroerendErfgoed/crabpy_pyramid#25

@koenedaele koenedaele modified the milestones: 0.8.0, 0.7.1 Mar 8, 2017
@koenedaele
Copy link
Member

Denk dat dit probleem wel kan opgevangen worden met de nieuwe REST service (#45)

@koenedaele koenedaele removed this from the 0.8.0 milestone Apr 19, 2017
@claeyswo
Copy link
Member Author

Zou op dit ogenblik zeer goed van pas komen.

@koenedaele
Copy link
Member

Bij de WS Capakey is het dacht ik niet op te vangen. Geen idee hoe het nu in de REST versie gaat werken. Lijkt me best dat we eerst de bugs oplossen en dan de REST versie deployen op het geoportaal zodat we kunnen zien waar we nu staan.

@claeyswo
Copy link
Member Author

Je kan op het moment van oorspronkelijke falen toch de ws.fault loggen?

@claeyswo claeyswo assigned Wim-De-Clercq and unassigned BartSaelen Jun 18, 2019
@Wim-De-Clercq
Copy link
Contributor

Wim-De-Clercq commented Jun 19, 2019

Sinds python3 heb je raise xxx from yyy waar de xxx exception dan een __cause__ atribuut heeft die yyy bevat.

En met future lib voor python2 compatibility:

# Python 2 and 3:
from future.utils import raise_from

raise_from(DatabaseError('failed to open'), exc)

Default logging (python 3) van zo'n error is dan zoals:

Traceback (most recent call last):
  File "/home/wim/.PyCharm2018.3/config/scratches/scratch_2.py", line 7, in main
    something()
  File "/home/wim/.PyCharm2018.3/config/scratches/scratch_2.py", line 2, in something
    raise ValueError("Original error")
ValueError: Original error

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/wim/.PyCharm2018.3/config/scratches/scratch_2.py", line 13, in <module>
    main()
  File "/home/wim/.PyCharm2018.3/config/scratches/scratch_2.py", line 9, in main
    raise TypeError("New error.") from e
TypeError: New error.

voor volgende code:

def something():
    raise ValueError("Original error")


def main():
    try:
        something()
    except Exception as e:
        raise TypeError("New error") from e


try:
    main()
except Exception as e:
    print(e.__cause__)  # "Original error"
    print(e)  # "New error"
    raise

Note: die default logging van "The above exception was the direct cause of the following exception:" is wel enkel vanaf python3, zelfs met de future lib in python2.
Default __cause__ in python3 is None, in python2 is dat AttributeError (raised)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants