[RFC] newFileStream(string, FileMode) returns nil

[vegansk]

newFileStream(string, FileMode) returns nil if it can't open file. Maybe this API should be coherent with system.open?

[dom96]

system.open returns a bool. I think the current behaviour of newFileStream is consistent with that of open.

open(filename) raises an exception whereas newFileStream(filename) returns nil on error.

Should this behaviour be made consistent?

[genotrance]

Many calls to open() raise an error - databases, json, memfiles, etc. Raising an exception seems to be the consistent method.

[Araq]

We need an openFileStream proc that raises an exception. The existing newFileStream needs to stay, too much code depends on it.

[twetzel59]

+1
An openFileStream sounds really nice

[data-man]

Or to add one more parameter (raiseException, default is true) to newFileStream.

[twetzel59]

@data-man I like the simpicity and intuitiveness of you suggestion.

My concern is that the behavior will not be consistent, and this leads to less documented/understandable APIs...

Also, the default arg is a breaking change.
For example,

proc readImage(filename: string not nil): Image {.raises[ImageError].} =
  var stream = newFileStream()
  if not stream.isNil:
    #blah
  else:
    raise newException(ImageError, "failed")

After changing this, the above no longer will work as expected. With the raises pragma, it won't compile, either.

[twetzel59]

@Araq, should I try to implement this? This would be my first contribution, and it seems both easy and doable, while still being helpful.

If the RFC process still needs more discussion, that's fine too :)

[Araq]

@twetzel59 cool, go for it.

[twetzel59]

@Araq, I'm working on it now, and I was wondering about your opinion on this: will implementing the new proc deprecate the old newFileStream(string; FileMode; int)?

[twetzel59]

I have implemented it. For now, I am going to not add the deprecated pragma, but I am going to update newFileStream docs to reflect the change.