hts_log_error() extension for better error reporting

Open
#1,397 5 comments 0 reactions 1 assignee View on GitHub

@whitwham is already working on this.

Since Feb 15, 2022.

Assessment

This issue has not been assessed yet.

Description

Hi there!

This is more of a general suggestion to improve error reporting, but I'll illustrate it with a concrete example.

I have started using the sam/bam/cram functionality recently, and got an (expected) error "The input is not sorted" on an unsorted bam file during testing. This error is reported in bam_plp_push() here, but not propagated from there to the original caller of the function - the error status gets lost.

My code calls bam_plp_auto(), and checks the result for null to detect whether the current position is usable (I gathered that this is the way this is to be used). That function returns a bam_plp_s* (typedef'ed as bam_plp_t), which however is only declared in the sam.h header, and then defined in sam.c here. Hence, the bam_plp_t field error, which is correctly set by bam_plp_push(), is not accessible from my code to check whether an error occurred.

Furthermore, hts_log() here prints the error directly to stderr, and hence further complicates for me to catch this and report any errors (in my case, via throwing an exception in C++).

It seems hence impossible for me to detect in my code whether a file has simply ended or has an error during iteration.

This all is of course only an example, and seems applicable to many other functions as well. Am I overlooking a simple solution here? What would be a good way of solving this?

One idea that might improve the situation is to offer to set a callback function that gets called in hts_log() with the htsLogLevel and the final error message. Users could then set this callback, and react in their own code to the error message, for example by throwing an exception (or whatever C users do in that situation :-D).

Thank you in advance and all the best
Lucas

Dominant language
C
Stars
950
Forks
475
Avg merge
3d 13h
Merged PRs (30d)
11

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from samtools/htslib

All issues in samtools/htslib

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.