:set -fbreak-on-exception in GHCi causes exception in readFile
Perhaps I don't quite get how this works, but when I :set -fbreak-on-exception in GHCi, I get an exception using readFile. It reads the entire file and then throws what appears to be an EOF exception. Prelude> readFile "blah.txt"
"blah\nblah\nblah\nStopped at <exception thrown> _exception :: e = GHC.Exception.SomeException (GHC.Exception.:DException _
(GHC.Show.:DShow ...) ....) (GHC.IOBase.IOError Nothing GHC.IOBase.EOF ....)
When I :set -fno-break-on-exception, I see no exception. I thought that lazy IO reads until it reaches the EOF, then closes the file. This happens with both 6.10.1 and 6.8.3, so perhaps this is standard stuff, and I'm missing something. Regards, Sean
On Nov 20, 2009, at 12:25 , Sean Leather wrote:
Perhaps I don't quite get how this works, but when I :set -fbreak-on- exception in GHCi, I get an exception using readFile. It reads the entire file and then throws what appears to be an EOF exception.
I believe that's normal; the runtime normally handles the exception itself, so you normally don't see it, but in principle you could catch it and perhaps do finalizer-ish things. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
This is by design, -fbreak-on-exception breaks on any exception, be it captured or not, even on library code. I am not sure how readFile is implemented internally, but it probably reads from the file until an eoferror is thrown and then captures it gracefully. There is another debugger flag, -fbreak-on-error, which only breaks on unhandled exceptions. Is this what you want ? Regards, pepe On 20/11/2009, at 18:25, Sean Leather wrote:
Perhaps I don't quite get how this works, but when I :set -fbreak-on-exception in GHCi, I get an exception using readFile. It reads the entire file and then throws what appears to be an EOF exception.
Prelude> readFile "blah.txt" "blah\nblah\nblah\nStopped at <exception thrown> _exception :: e = GHC.Exception.SomeException (GHC.Exception.:DException _ (GHC.Show.:DShow ...) ....) (GHC.IOBase.IOError Nothing GHC.IOBase.EOF ....)
When I :set -fno-break-on-exception, I see no exception.
I thought that lazy IO reads until it reaches the EOF, then closes the file. This happens with both 6.10.1 and 6.8.3, so perhaps this is standard stuff, and I'm missing something.
Regards, Sean _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Fri, Nov 20, 2009 at 18:31, Jose Iborra wrote:
This is by design, -fbreak-on-exception breaks on any exception, be it captured or not, even on library code.
Ah, that's what I missed. I would've guessed that it only breaks on uncaught exceptions.
I am not sure how readFile is implemented internally, but it probably reads from the file until an eoferror is thrown and then captures it gracefully.
That's what I expect, too. I went fishing, but didn't find the exact spot where that happens within a few minutes.
There is another debugger flag, -fbreak-on-error, which only breaks on unhandled exceptions. Is this what you want ?
Probably. Now I see the difference in [1]. Thanks! [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#... Regards, Sean
On Nov 20, 2009, at 13:02 , Sean Leather wrote:
On Fri, Nov 20, 2009 at 18:31, Jose Iborra wrote: This is by design, -fbreak-on-exception breaks on any exception, be it captured or not, even on library code.
Ah, that's what I missed. I would've guessed that it only breaks on uncaught exceptions.
But then you can't easily debug your exception handling code. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
Hello Sean, Friday, November 20, 2009, 8:25:08 PM, you wrote: heh, the well known problem, i've seen it in Delphi. it even has a large list of exceptions to be ignored, but i think that better way will be to set this on a per-package and per-module basis
Perhaps I don't quite get how this works, but when I :set -fbreak-on-exception in GHCi, I get an exception using readFile. It reads the entire file and then throws what appears to be an EOF exception.
Prelude>> readFile "blah.txt"
"blah\nblah\nblah\nStopped at <exception thrown> _exception :: e = GHC.Exception.SomeException (GHC.Exception.:DException _ (GHC.Show.:DShow ...) ....) (GHC.IOBase.IOError Nothing GHC.IOBase.EOF ....)
When I :set -fno-break-on-exception, I see no exception.
I thought that lazy IO reads until it reaches the EOF, then closes the file. This happens with both 6.10.1 and 6.8.3, so perhaps this is standard stuff, and I'm missing something.
Regards, Sean
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
heh, the well known problem, i've seen it in Delphi. it even has a large list of exceptions to be ignored, but i think that better way will be to set this on a per-package and per-module basis
Yes, that might be a better idea. In general though, it sounds as if -fbreak-on-error will be useful more often than -fbreak-on-exception. I was not aware of the former, and I had the latter in my .ghci. I think I'll remove it from there and just use the OPTIONS pragma when needed.
Perhaps I don't quite get how this works, but when I :set -fbreak-on-exception in GHCi, I get an exception using readFile. It reads the entire file and then throws what appears to be an EOF exception.
Prelude>> readFile "blah.txt"
"blah\nblah\nblah\nStopped at <exception thrown> _exception :: e = GHC.Exception.SomeException (GHC.Exception.:DException _
(GHC.Show.:DShow ...) ....)
(GHC.IOBase.IOError Nothing
GHC.IOBase.EOF ....)
When I :set -fno-break-on-exception, I see no exception.
I thought that lazy IO reads until it reaches the EOF, then closes the file. This happens with both 6.10.1 and 6.8.3, so perhaps this is standard stuff, and I'm missing something.
Regards, Sean
participants (4)
-
Brandon S. Allbery KF8NH -
Bulat Ziganshin -
Jose Iborra -
Sean Leather