<div dir="ltr">If you compile with -prof you can use the traceStack function from Debug.Trace.  That's something.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 27, 2015 at 8:56 AM, Dennis Raddle <span dir="ltr"><<a href="mailto:dennis.raddle@gmail.com" target="_blank">dennis.raddle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>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" </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><div>For example, instead of using head xs I can write</div><div><br></div><div>x = case xs of {y:_ -> y}</div><div><br></div><div>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.</div><div><br></div><div>Any comments welcome.</div><div><br></div></div>
<br>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br></blockquote></div><br></div>