Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle failure for readFileSync #22

Open
wbinnssmith opened this issue Apr 22, 2014 · 6 comments
Open

Handle failure for readFileSync #22

wbinnssmith opened this issue Apr 22, 2014 · 6 comments

Comments

@wbinnssmith
Copy link

In node I can wrap a call to readFileSync in a synchronous try/catch:

var fs = require('fs');

try {
  fs.readFileSync('./does/not/exist');
} catch (e) {
  console.log('caught!');
}

and running it will write caught! but running through browserify -t brfs gives

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: ENOENT, open './does/not/exist'

Is there a way that the same thing with brfs? I know that brfs processes the source statically, but I'm doing things like running the source through envify first and the fs call could fail and stop the build. Probably does so for the best, but I was wondering if there is a way to inline an empty string, undefined, etc.

Thanks substack!

@wbinnssmith
Copy link
Author

Just a thought, but maybe brfs could inline something like throw new Error in place of the inlined string in these cases. That way, it could be caught when the browserified code is run and the catch block would be reached at runtime.

@ghost
Copy link

ghost commented Apr 23, 2014

What is your particular use case for this feature?

@wbinnssmith
Copy link
Author

I'm reading in a manifest generated by gulp-rev and writing it into browserified output so that lookups of unrevved-to-revved assets can be shared in node and the browser. In development, I'm not writing this file, and so the fs.readFileSync call in my module fails and I can't do anything to stop it (the same is true of requireing the json file). In my use case I'm tempted to just write a file with {} just to get around the issue but I figured it could be useful in other ways.

@aneeshd16
Copy link

Any update on this issue?
My use case involves reading a custom configuration file for settings and then falling back to a default configuration file if the custom one is not found.

@mattdesl
Copy link
Collaborator

This is interesting but I'm not 100% sure about it. I like that brfs currently emits a build error; it allows broken files to show in the browser with budo and errorify, and most of the time it represents a fatal programmer error rather than something you would try/catch.

I will brew on it. 😄

@mk-pmb
Copy link

mk-pmb commented Jul 19, 2016

Sorry for sending that IIFE suggestion too early. Example code for the custom config use case:

'use strict';
var fs = require('fs'), config,
  defaultConfig = require('../package.json').defaultConfig;

try {
  config = fs.readFileSync(__dirname + '/customConfig.json', 'utf8');
  config = JSON.parse(config);
} catch (readOrJsonErr) {
  config = null;
}
if (!config) { config = defaultConfig; }
console.log('sync:', config);

fs.readFile(__dirname + '/customConfig.json', 'utf8', function (readErr, cfg) {
  cfg = ((!readErr) && JSON.parse(cfg)) || defaultConfig;
  console.log('async:', cfg);
});

most of the time it represents a fatal programmer error rather than something you would try/catch.

Maybe brfs can inline throwing IIFEs in cases where it's easy to detect that the read operation is called inside a try {} block?

For instances where the code authors intend to use brfs, we could add brfs APIs that convey more info about how to translate them, like brfs.read{,dir}{Expect,IfAvail,OrNull}{,Sync} (Expect: or build error, IfAvail: or throw/ send error to callback, OrNull: on error, pretend successful read with null as data). Usually I'd say convenience functions like OrNull belong into their own library, but then we'd need a way to tell brfs how to handle which call in that library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants