Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Figure out error handling #2

Closed
Closed
Assignees
sfackler
@sfackler

Description

@sfackler

Onmaster, everything returns aResult<T, ~str>. Onnative, error "handling" is task failure. Neither of these options are particularly great.

TheResult strategy imposes an annoying burden on users who don't care about handling SQL syntax errors in the common case.~str is also not the appropriate type for errors, but that's more easily fixable.

On the other hand, usersdo sometimes want to do reasonable things with failure, especially when connecting and potentially when querying (e.g. if you wanted to rewrite psql).

One option is to have something like

impl PostgresConnection {    pub fn connect(url: &Url) -> PostgresConnection {        match PostgresConnection::try_connect(url) {            Ok(conn) => conn,            Err(err) => fail!(err)        }    }    pub fn try_connect(url: &Url) -> Result<PostgresConnection, PostgresConnectionError> {        ....    }}

and so on for all of the relevant methods. I think this is probably the most workable solution.

Whatever the solution is, the error object type should be robust. We should be able to parse the SQLSTATE value of the ErrorResult to get things likeNotNullViolation vsForeignKeyViolation.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions


    [8]ページ先頭

    ©2009-2025 Movatter.jp