A no-no in my book (found in Cabal)

A recent “find” in Cabal made me think of this:

In my opinion the final decision of what to do in case of an error belongs in the application, not in libraries.

I’m sure there are exceptions to this, but I believe it’s good as a guiding principle when defining APIs.

Here’s the code in Cabal that breaks this rule. Basically, if you write an application and call readPackageDescription on a cabal file with errors then your application is terminated (the call to dieWithLocation ends up calling exitWith). I would much rather it returned an error (e.g. based on Either) so I can decide what to do with bad cabal files myself.

I’ve raised a ticket for it of course ;-)

⟸ Another reason to create distro-specific packages for Haskell modules More fun with Cabal, visualising dependencies ⟹


As noted in the ticket, you can handle the errors however you like if you use parsePackageDescription.


@Duncan, thanks for pointing that out.

Leave a comment