Parsing error handling and MAC retrieval on new snapshots #27

Changed form validation onto the fields, because if the form itself failed but the file was read, then the file_input field showed a success icon (whilst displaying error messages), which is confusing given that it is the only field.

Done again PR #25. Also reworked the exception handling and error messages on upload/import views. Added a success message to display for these views. Changed form validation onto the fields, because if the form itself failed but the file was read, then the file_input field showed a success icon (whilst displaying error messages), which is confusing given that it is the only field.

rskthomas changed title from ~~WIP: Parsing error handling and MAC retrieval on new snapshots~~ to Parsing error handling and MAC retrieval on new snapshots

2024-11-11 18:02:36 +00:00

pedro commented

2024-11-12 00:38:19 +00:00

I am confused by the raises in proposed code (I also found other ones in the current django app), maybe the use of raise you are doing here is fine, just review it again. Because I saw how a generic rise in django command crashed the application, but maybe when you use this kind of raise everything is fine https://docs.djangoproject.com/en/dev/ref/exceptions

I found a portion of the code that it is old (with other parts might happen the same!), this part; we don't need. We don't need the if settings.DEBUG anymore, we have a logger configuration that when DEBUG is there, a trace is always generated. And the old message is shorter and clearer than the new one. Done here -> fc849f0360

I am confused by the raises in proposed code (I also found other ones in the current django app), maybe the use of raise you are doing here is fine, just review it again. Because I saw how a generic rise in django command crashed the application, but maybe when you use this kind of raise everything is fine https://docs.djangoproject.com/en/dev/ref/exceptions I found a portion of the code that it is old (with other parts might happen the same!), this part; we don't need. We don't need the if settings.DEBUG anymore, we have a logger configuration that when DEBUG is there, a trace is always generated. And the old message is shorter and clearer than the new one. Done here -> https://farga.pangea.org/ereuse/devicehub-django/commit/fc849f0360dc0e9aad251c18cab8b7e441a1c0fa

pedro added 1 commit 2024-11-12 13:33:16 +00:00

fc849f0360 recover old up_snapshot functionality

- We don't need the if settings.DEBUG anymore, we have a logger
configuration that when DEBUG is there, a trace is always generated
- restore old error message that is shorter and clearer than the new one

pedro added 1 commit 2024-11-12 13:38:21 +00:00

57f9e28466 up_snapshots: simplify and clarify errors

specially, do not halt in case of errors, just print them in logs

pedro commented

2024-11-12 13:40:55 +00:00

Reviewed raises with @cayop ( 57f9e28466 )

@cayop needs to test it before merge

Reviewed raises with @cayop ( https://farga.pangea.org/ereuse/devicehub-django/commit/57f9e28466f11ec7903f5f55ddedfbb2648b42d9 ) @cayop needs to test it before merge

pedro changed target branch from real_main to main

2024-11-12 13:46:11 +00:00

pedro force-pushed pr_25 from 57f9e28466 to 65788b36af

2024-11-12 13:49:05 +00:00

Compare

pedro merged commit b7d7b9041d into main

2024-11-12 13:57:05 +00:00

pedro referenced this issue from a commit

2024-11-12 13:57:07 +00:00

Merge pull request 'Parsing error handling and MAC retrieval on new snapshots' (#27) from pr_25 into main

pedro deleted branch pr_25

2024-11-12 13:57:07 +00:00

rskthomas commented

2024-11-12 14:00:53 +00:00

Ive use the exceptions mostly to catch the errors and propagate them with a cleaner message (for ValidationError to display). Mostly because those are shown to the user, which may not know what did wrong. If there is a better and more idiomatic way of raising errors let me know as im new to django.

Sign in to join this conversation.

No reviewers

No Label

No Milestone

No project

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: ereuse/devicehub-django#27