Sorry I was showing a code fragment as the actual code is a bit rubbish!
Truncated version at the end, but the point was that it was an error of
type *os.PathError. It appears that the os package is creating a new error:
https://golang.org/src/os/file_unix.go?s=4493:4559#L170
based upon the return from the syscall. This obscures the actual source of
the error and means the only way of interpreting the cause of the error is
to parse the string.
I get that os specific things like file system errors are going to be very
os specific, but is this really our only option? Could we not pass the
error value through the Wrap method Dave suggests? Could these errors not
have error types we could inspect? Could some of these error types "File
already exists", "Cannot create file, already exists and is a directory"
etc that will be common across OSs be collected into come common error
types. That will never catch them all, but if the common ones can be caught
it's got to reduce the effort of handling this stuff.
Regards
-----
out, err := os.Create(potential_file_name)
switch t := err.(type) {
case *os.PathError:
switch t.Err {
case os.ErrNotExist:
log.Fatal("Invalid filename", potential_file_name)
case os.ErrInvalid:
log.Fatal("Invalid argument", potential_file_name)
default :
switch t.Err.Error(){
case "is a directory":
// Case we are trying to catch
return
default:
log.Fatalf("Unknown
os.PathError\n\"%s\"\n%v\n,Type:%t\nDir:%s\nUrl:%s\n", potential_file_name,
t.Err, t.Err, dir_str, fetch_url)
}
}
case nil:
// nothing to see here
default:
log.Fataf("Error is of type %T,n", err)
}
On Monday, 2 October 2017 15:25:37 UTC+1, Jakob Borg wrote:
>
> Presumably OP means that the actual type of the error is not exported and
> cant be type switched upon.
>
> However, the syscall errors are typically syscall.Errno and can be
> inspected for their numeric value, obviating the need to look at the
> string. It's rather platform specific though at that point.
>
> //jb
>
> > On 2 Oct 2017, at 15:59, Jan Mercl <0xj...@gmail.com <javascript:>>
> wrote:
> >
> > On Mon, Oct 2, 2017 at 2:51 PM Chris Hopkins <cbeho...@gmail.com
> <javascript:>> wrote:
> >
> > > Yes, it has dynamic type. That doesn't mean you can't test against it.
> > > I thought the preferred way to to handle errors was for a package to
> expert the error variables, then you could test for those variables as in
> the above code.
> >
> > The code shown uses only type switches, so it will always work. I don't
> know what "does not work".
> >
> >
> > --
> > -j
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com <javascript:>.
> > For more options, visit https://groups.google.com/d/optout.
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
