Issue 391 Do not blame the user when inappropriate to do so (userError)

Title Do not blame the user when inappropriate to do so (userError)
Priority wishlist Status resolved
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, kowey, simonmar, thorkilnaur, tommy
Assigned To

Created on 2007-01-12.16:34:18 by simonmarhaskell, last changed 2009-10-24.00:39:25 by admin.

msg1407 (view) Author: simonmar Date: 2007-01-12.16:34:13
David Roundy wrote:
> I'm cc'ing this to the bug tracker to create a bug for the feature request
> described below, which came up from an idea of Juliusz...
> On Fri, Jan 12, 2007 at 01:19:36AM +0100, Josef Svenningsson wrote:
>>On 1/11/07, David Roundy <droundy@darcs.net> wrote:
>>>I think we'd really like to apply it not to the method, but to the instance
>>>itself.  So that use of the Show instance of Control.Exception.Exception
>>>would be deprecated.  This'd be more severe, since there might be classes
>>>that depend on a show instance, but don't actually use it.
>>>Another possibility for this particular problem would be to be able to
>>>rewrite the show instance.  If we could just remove the stupid "User
>>>error:" text from the show instance, I don't think it'd be a bug to use it
>>I did a little testing and it turns out that you can actually achieve
>>what you want. Just write another Show instance for C.E.Exception and
>>import it wherever there is a possibility that a bad show might be
>>lurking. GHC will only complain about duplicate instances if you
>>actually use a method from the Show class with the particular type
>>which has several instances. So GHC is doing exactly what you want!
> Cool! (I would have expected it to cause trouble even when we don't use
> show.) I think this'd be a great little cleanup.  We could put the import
> in impossible.h, which is #included almost everywhere.  :)
> For the benefit of the bug tracker, the idea is that we want to avoid using
> the Show instance of Control.Exception.Exception, which has the
> disadvantage of sometimes displaying "User error: xxx" when we failed with
> code such as error "xxx".  This isn't the user's fault, and we should never
> use this show instance (except if we've already checked that the exception
> is not a UserException or whatever it's called).  Adding this code to
> impossible.h will probably also require fixing a few (bad) uses of show.

I suggest not using userError, use a more descriptive exception type with 
dynamic exceptions (throwDyn, catchDyn).  This is what we do in GHC:


To avoid the use of IO.bracket, there are a couple of options:

   - Use -hide-package haskell98.  This probably works in 6.4.x.  No doubt
     you'll have to change a lot of code to import the base-package version
     of a lot of haskell98 modules, but you get to avoid a few of these legacy
     issues in one go.

   - the other way is to have a local 'IO' module that will override the
     haskell98 one.  This only works with GHC 6.6, however.

   - or just search for 'import IO' and replace them all with
     'import System.IO'.

msg1850 (view) Author: kowey Date: 2007-07-17.05:12:29
This is fixed by Juliusz's prettyException, right?  Now released in 1.0.9. 
There might be some cases where we fail to use prettyException (issue73) but for
the most part, I'd consider this fixed.  Do let me know if I'm glossing over
Date User Action Args
2007-01-12 16:34:18simonmarhaskellcreate
2007-03-09 08:33:25koweysetnosy: droundy, tommy, beschmi, kowey, simonmarhaskell
title: GHC and flagging use of a given constant -> Do not blame the user when inappropriate to do so (userError)
2007-07-17 05:12:30koweysetstatus: unread -> resolved
nosy: droundy, tommy, beschmi, kowey, simonmarhaskell
messages: + msg1850
2009-08-06 17:45:36adminsetnosy: + markstos, jast, Serware, dmitry.kurochkin, darcs-devel, zooko, dagit, mornfall, simon, thorkilnaur, - droundy, simonmarhaskell
2009-08-06 20:41:25adminsetnosy: - beschmi
2009-08-10 22:01:00adminsetnosy: + simonmarhaskell, - markstos, darcs-devel, zooko, jast, dagit, Serware, mornfall
2009-08-25 17:57:32adminsetnosy: + darcs-devel, - simon
2009-08-27 13:50:10adminsetnosy: tommy, kowey, darcs-devel, simonmarhaskell, thorkilnaur, dmitry.kurochkin
2009-10-24 00:39:25adminsetnosy: + simonmar, - simonmarhaskell