Refactor error handling #295

Closed
opened 2020-12-14 05:35:08 +00:00 by noerw · 2 comments
Member

There's quite a lot of log.Fatal() in the code base, even though we have facilities to pass errors all the way up.
We should have a single error handler.

There's quite a lot of `log.Fatal()` in the code base, even though we have facilities to pass errors all the way up. We should have a single error handler.
noerw added the
kind
refactor
label 2020-12-14 05:35:08 +00:00
6543 added this to the v0.7.0 milestone 2020-12-14 10:29:48 +00:00
Author
Member

While at it, we can introduce proper error codes (at least for common cases like 404 etc).
urfave/cli has facilities for this (cli.Exit(msg, code)).
Question is: Is it okay to introduce cli dependency in modules/tasks for this? @6543

While at it, we can introduce proper error codes (at least for common cases like 404 etc). urfave/cli has facilities for this (`cli.Exit(msg, code)`). Question is: Is it okay to introduce `cli` dependency in `modules/tasks` for this? @6543
Owner

introduce cli dependency in modules/tasks for this?

I'm not a fan of that ...

but we could intorduce a custom error, to pass throug the code & msg

> introduce cli dependency in modules/tasks for this? I'm not a fan of that ... but we could intorduce a custom error, to pass throug the code & msg
6543 closed this issue 2020-12-16 16:18:12 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/tea#295
No description provided.