Thanks, that's really useful.
It never occurred to me that you could cast it to a type after the error
has been appended - my attempts to print out the type that was being
returned didn't show this as an option.
I'll have a play.
Thanks again
On Monday, 2 October 2017 17:20:41 UTC+1, Marvin Re
* Marvin Renich [171002 11:31]:
> * Chris Hopkins [171002 10:52]:
> > 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
* Chris Hopkins [171002 10:52]:
> 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 argume
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 retur
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 poin
On Mon, Oct 2, 2017 at 2:51 PM Chris Hopkins 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 s
So I guess another way of phrasing this question is, is this post gospel:
https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully
If so, is there a plan to backport this into the whole standard library?
Regards & Apoligies
Chris
On Monday, 2 October 2017 13:51:24 UTC+1,
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.
For the packages that don't do that you can call Error on the erro
On Mon, Oct 2, 2017 at 2:19 PM Chris Hopkins wrote:
I'm not sure I understand: error is an interface and it always has some
dynamic type when non-nil. But that type cannot by string b/c string does
not implement the error interface.
--
-j
--
You received this message because you are subscrib
Hi,
I'm used to doing error handling like the following:
out, err := os.Create(potential_file_name)
switch t := err.(type) {
case *os.PathError:
switch t.Err {
case os.ErrNotExist:
etc...
However I came a cropper with an error that I traced to coming out of
syscall - specifically
10 matches
Mail list logo
