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

Add specific type Errors #6

Open
AndreasBackx opened this issue Mar 29, 2016 · 4 comments
Open

Add specific type Errors #6

AndreasBackx opened this issue Mar 29, 2016 · 4 comments

Comments

@AndreasBackx
Copy link

The API documentation has a ton of errors listed, would it be possible to have these exact errors/exceptions be raised by the library? Currently we have to check for the errors inside of the Error's error (that sentence is a bit ridiculous, but it makes it clear).

We end up with the following constantly:

try:
    instance.from_api(
        instance.api.create,
        params=given
    )
except GoCardlessProError as e:
    raise DjangoGoCardlessException.from_gocardless_exception(e)
instance.save(*args, **kwargs)

The DjangoGoCardlessException.from_gocardless_exception(e) would raise the exception that should've been raised by the library.

Instead of that something like this:

try:
    instance.from_api(
        instance.api.create,
        params=given
    )
except AccessTokenNotFound as e:
    # Perhaps not catch it here, but elsewhere.
@greysteil
Copy link

Hi Andreas,

Thanks for this. I'll leave it to @hmarr, who's on holiday right now but back in the next few days.

@AndreasBackx
Copy link
Author

I feel like the library doesn't offer a lot in terms of saving development time. I wish there was a more advanced library available for GoCardless that perhaps wasn't generated by Crank. Perhaps open source Crank because we also essentially don't know what Crank does besides generate this library?

A simple example of a quality of life change would be that the resources from the library could do some simple validation locally. Validation like required fields and min/max length fields. Most of these validations probably done by a project using this library.

@hmarr
Copy link
Contributor

hmarr commented Apr 5, 2016

Thanks for reporting this @AndreasBackx. I can definitely see how more granular error types would help.

Currently, it's a non-trivial change as the library is generated from our API schema, which doesn't contain details of error types. However, adding errors to the schema is something we'll consider in due course.

We're keen to open source Crank, and plan to in the future, but unfortunately can't commit to a date right now.

@AndreasBackx
Copy link
Author

Any update on this? I don't see Crank open sourced yet nor does this issue seem to have evolved any further after over a year.

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

No branches or pull requests

3 participants