[Haskell-beginners] comment on this debugging trick?

[Jeffrey Brown]

Elliot Cameron, very smart guy, once advised me to make illegal state
invalid. Jake Brownson, another, recommended trying to use Maybes and
Eithers instead of throwing exceptions. I'm having trouble coming up with
examples but I think they're both helpful.

That said, your trick of replacing, for instance, head with a case
statement seems good to me ...

On Fri, Nov 27, 2015 at 5:56 AM, Dennis Raddle <dennis.raddle at gmail.com>
wrote:

> When I design my code, I am aware of the properties I expect my internal
> data representations to have, or I want input data to conform to my
> expectations. For example, right now I'm writing code that reads MusicXML.
> MusicXML is a crazy language, way too complicated for what it does, and the
> music typesetters that export MusicXML all do their own idiosyncratic
> things with it. I'm only reading the output of one typesetter, Sibelius,
> and although I don't know the internals of Sibelius, I can make some
> assumptions about what it's going to produce by a few examples, plus my
> application doesn't use the full range of MusicXML. I don't need to handle
> every case, is what I'm getting at.
>
> However, if I should have been wrong about my assumptions when I wrote the
> code, I don't want my program to behave erratically. I want to find out
> exactly what went wrong as soon as possible.
>
> Previously, I was including a lot of exception throwing, with each
> exception having a unique message describing what had happened, and in
> particular describing where in the code it is located so I can find the
> problem spot
>
> If I throw generic error messages like "Error: problem parsing" and I have
> many of those located in the code, I need the debugger to find it. Same if
> I use things like "fromJust" or "head"
>
> I haven't had good experiences using the debugger. Maybe that's my fault,
> but I like that I can locate my unique exceptions and that they are
> descriptive.
>
> But a month ago I decided this system is pretty ugly. It bloats the code a
> lot, and requires writing a lot of messages for situations that will
> probably never occur.
>
> I am trying a different method now. I write the code so that surprising
> behavior will result in a case or pattern exhaustion, which produces a run
> time message with a file name and line number. I'm not sure why ghc gives
> the location for a case exhaustion, but not something like "head".
>
> For example, instead of using head xs I can write
>
> x = case xs of {y:_ -> y}
>
> This is a little bloat but not too bad. Most of the time I'm actually
> structuring cases and patterns, and it actually helps me to simplify code
> to think of how to write it with the fewest cases and so that a case
> exhaustion will indicate something pretty specific.
>
> Any comments welcome.
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>


-- 
Jeffrey Benjamin Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20151127/6448bc1c/attachment-0001.html>