Design a way to expose internal error states for debugging
@pavel-kirienko já está trabalhando nisso.
Desde 18/7/2023.
Avaliação
Esta issue ainda não foi avaliada.
Descrição
As is appropriate for libudpard, the error system exposed to applications is very simple. There are times, however, when deeper introspection would be helpful. For example, when first integrating with a system the integrator is likely to make a few mistakes that are atypical for a healthy system but which are common misconceptions or just dumb mistakes caused by the tendency of many to read variable names instead of documentation. There are not many of these conditions in our simple code base which makes it undesirable to design a normal error scheme to support this use case. One idea is to provide a -DDEBUG enabled structure that can store this type of error data when enabled (e.g. sort of a posix errno scheme). Other ideas are welcome but the end result would be to make libudpard a bit more friendly to new users.
- Linguagem predominante
- C
- Estrelas
- 22
- Forks
- 12
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Issues semelhantes
-
Add `CPC_TAKE_TILL_CHARS`Abertadifficulty: easy
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 64/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
-
performance solver
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
ChefKissInc/Inferno#319 ·
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 91/100
FreeJoy-Team/FreeJoy#275 ·