GithubHelp home page GithubHelp logo

Comments (5)

bogdaaamn avatar bogdaaamn commented on May 31, 2024 1

Oh yeah, of course! I wasn't thinking about printing the API errors AS THEY ARE, just getting a friendlier message.

For instance, when I used a weak password, instead of Failed to create user could've been Password too weak or something equivalent. But you solved this issue in UX with eb288c5, so atm I don't really have another use case.

I'll see if something else pops up.

from appwrite.

eldadfux avatar eldadfux commented on May 31, 2024

eb288c5

This commit should fix it. Will be released in 0.4.0, also available now on master branch.

from appwrite.

bogdaaamn avatar bogdaaamn commented on May 31, 2024

ok, perfect!

Based on this issue I was thinking of a feature that would also show what kind of error is, since we get it from the response. Not only Failed to create user or Failed to create team

I can make an issue and also work on it, if you find it useful @eldadfux!

from appwrite.

eldadfux avatar eldadfux commented on May 31, 2024

I think we should treat this as per case thing instead of a simple project-wide task that can affect all errors.

Exposing too much information when throwing errors can be considers as a security weakness in some cases and in other cases just passing to the client the API error AS IS can have a really bad UX as it might be too technical or just too long.

So basically we have the API error that are thrown from exceptions. Our error handler only show 4** error to the users and all other errors get 5** server error generic message. In dev mode the error are much more verbose for debugging.

The console manages errors in a per form error message logic.

@bogdaaamn let me know what you think.

from appwrite.

eldadfux avatar eldadfux commented on May 31, 2024

Thats a valid point. I think it will be good to review all the errors thrown inside the controllers and makes sure they are consisted.

Another thing I wanted to improve is to force better error handling inside the Utopia PHP validator interface. Currently this validator only support a description and that's not really the same thing as an error message.
https://github.com/utopia-php/framework/blob/master/src/Validator.php

Thinking about adding a message setter and getter and make Utopia use the message instead of the description when reporting errors.

from appwrite.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.