Currently, almost all errors are somewhat magic. Instead of explicit messages such as: What?, Where?, Why?. The embed-code often returns different types of panics with little or no meaningful information.
For example, one of the main CLI goals is to check whether the current embedding is up to date - now it simply panics instead of providing meaningful feedback.
Actions:
- All explicit `panics' should be reviewed to ensure they provide enough information to troubleshoot an issue. Keep message as short as possible but provide all the info that is needed.
- Some prechecks should be added to avoid `panics' originating from 3rd-party libraries. In short, we should handle all possible panics that can be anticipated from a domain perspective.
The general purpose of this issue is that when working with embedded code, if you make a mistake, such as using the wrong tag, forgetting something, or mistyping a fragment, the system response should be clear enough to help you fix the documentation instead of forcing you to roam around the embed-code-go codebase.
Currently, almost all errors are somewhat
magic. Instead of explicit messages such as:What?,Where?,Why?. Theembed-codeoften returns different types of panics with little or no meaningful information.For example, one of the main CLI goals is to check whether the current embedding is up to date - now it simply panics instead of providing meaningful feedback.
Actions:
The general purpose of this issue is that when working with embedded code, if you make a mistake, such as using the wrong tag, forgetting something, or mistyping a fragment, the system response should be clear enough to help you fix the documentation instead of forcing you to roam around the
embed-code-gocodebase.