-
Notifications
You must be signed in to change notification settings - Fork 30.1k
Commit
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -87,7 +87,9 @@ export class FileLogService extends AbstractLogService implements ILogService { | |||||
} | ||||||
|
||||||
private async initialize(): Promise<void> { | ||||||
await this.fileService.createFile(this.resource); | ||||||
if (!await this.fileService.exists(this.resource)) { | ||||||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
sandy081
Author
Member
|
if ((<FileOperationError>error).fileOperationResult === FileOperationResult.FILE_NOT_FOUND && isValidBasename(basename(input.preferredResource))) { |
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
sandy081
Oct 19, 2020
Author
Member
Sorry. I am not sure if error code FILE_NOT_FOUND
works for me. I am trying to create a file and an error is thrown if file exists already. From debug, I am getting FILE_MODIFIED_SINCE
error from the service. Is it the right error code?
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
bpasero
Oct 19, 2020
Member
@sandy081 yes that should work, it is thrown here:
throw new FileOperationError(localize('fileExists', "Unable to create file '{0}' that already exists when overwrite flag is not set", this.resourceForError(resource)), FileOperationResult.FILE_MODIFIED_SINCE, options); |
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
DBJDBJ
Oct 24, 2020
•
edited
Loading
edited
Basically, the theory goes:
"exceptions are just and only for exceptional situations", while returns are to be descriptive enough to be able to code a bit more involved return handling logic.
One does always finish with a "special structure" returned that will allow for "returns handling" which is not "error handling". Especially useful in situations like this where "the thing returned is not an error".
IO situations are a good example. Thus I might suggest returning a structure, something like { return_value, status_code }
... combination of the two allows for nontrivial passing out of the function and processing on the caller side. I might prefer this to exceptions:
return FileOperationOutcome (
// you do not want to spend CPU cycles on localized message making
// and returning, just pass the "message code" that caller might or might not use
// not all situations require human-readable messages
message_code( resource ),
// this is good
// this is where you pass the status to the caller
FileOperationResult.FILE_MODIFIED_SINCE,
// this looks like it might be better as an
// property of the file operations result
// unless it has a completely decoupled logic
options
);
Technically exception throwing catching mechanisms do lead to bigger and slower executables. But in the world of Electron users, that is hardly relevant.
Caveat Emptor: I am C/C++ head, although with a rich javascript lineage :) I am not helping. Changing a fundamental API right now is probably not an option.
@sandy081 if this is code that may block startup, a faster variant is to put the
createFile
around a try-catch block. Otherwise you pay an extra file access.