so I have found the culprit, by defining this function:<br><br>Import Debug.Trace<br><br>headMarker :: String -> [a] -> a<br>headMarker marker [] = trace marker (head [])<br>headMarker _ array = head array<br><br>and replacing calls to head to "headMarker "XX"", "headmarker "YY"" and so on.<br>
it works but I would really rather have a compiler/runtime based solution which would not force me to modify my code to track the bug (and would be simpler to use in case the problem comes from a library).<br><br>If anybody has an idea what I did wrong with the -xc and the -RTS I'm all ears... I'd love to test it and find out how to make that work reliably.<br>
<br>Emmanuel<br><br><div class="gmail_quote">On Tue, Nov 6, 2012 at 10:50 PM, Emmanuel Touzery <span dir="ltr"><<a href="mailto:etouzery@gmail.com" target="_blank">etouzery@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
you mean in combination with the RTS/profiling trick?<br>If I must do something like that, I'll just mark my code with debug lines or code the else situations (like making a headMarker with an extra parameter "String marker" and it will output the marker on stdoud if the array is empty), seems less work...<br>
<br>I was really hoping being able to fix it without having the modify the code, it's disappointing, I think.<div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Tue, Nov 6, 2012 at 9:47 PM, Christian Maeder <span dir="ltr"><<a href="mailto:Christian.Maeder@dfki.de" target="_blank">Christian.Maeder@dfki.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Usually, these head calls are in your code. Do "fgrep head" on your sources and replace all suspicious occurrences. Use "let h : _ = l in ..." and "h" instead of "head l" for proper positions.<br>
<br>
HTH Christian<br>
<br>
Am 06.11.2012 12:44, schrieb Emmanuel Touzery:<div><div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I'm getting really frustrated by error handling in haskell. By this<br>
I mean "assert"-like errors. Which means, something that should never<br>
happen, happens. This will happen in the development and deployment of<br>
software of any size.<br>
When coding the feature you'll say, I don't need to handle the<br>
"Nothing" case, because it will never happen, or almost never, and this<br>
is not critical production software.<br>
<br>
But if one day it happens you find yourself with a several thousand<br>
lines program and all you have to debug is the input data (most of the<br>
time anyway, sometimes not even that) and this error message (for<br>
instance):<br>
<br>
*** Exception: Prelude.head: empty list<br>
<br>
And you don't know even, did you call "head" or maybe a library you<br>
are using called it.<br>
<br>
This is really poor compared to what Java, python and others<br>
offers. I can understand that it's difficult to provide a stack trace,<br>
especially with lazy evaluation, but at least the function name and<br>
maybe a line number... Actually I don't know why it would be so<br>
difficult to also give me the values of the parameters of the<br>
function... using print and if it's a pure function it intuitively<br>
doesn't seem difficult.<br>
<br>
I've tried ghci with :trace and ":set -fbreak-on-exception" and I<br>
got nowhere. It breaks in things which are not important (I have no idea<br>
where it breaks, it claims an exception was thrown, maybe but not in my<br>
code and it never reaches my code for sure). After hitting ":continue"<br>
many times, I get to my exception and there I didn't manage to get<br>
useful information (:hist never printed me anything).<br>
<br>
But I would like not to have to use ghci at all. And to avoid<br>
having to write all over the place in my code these "else" and case<br>
situations for things I assume are impossible (these are cases I would<br>
not write in other modern languages).<br>
<br>
This is a feature for which I would be ready to pay a 50% speed<br>
penalty and 50% memory use penalty.<br>
<br>
I understand if it's the haskell way of writing all those else<br>
clauses... But I think in that case it really makes it compare<br>
negatively to other languages. It would be a real minus in my opinion<br>
(including to code readability).<br>
<br>
I have read (quickly) those but didn't find the solution there:<br>
<a href="http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/ghci-debugger.html" target="_blank">http://www.haskell.org/ghc/<u></u>docs/7.0.1/html/users_guide/<u></u>ghci-debugger.html</a><br>
<a href="http://book.realworldhaskell.org/read/error-handling.html" target="_blank">http://book.realworldhaskell.<u></u>org/read/error-handling.html</a><br>
<br>
Any advice will be welcome! I really hope I missed something.<br>
<br>
Emmanuel<br>
<br>
</blockquote>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>