Handle failure for readFileSync

[wbinnssmith]

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]

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]

What is your particular use case for this feature?

[wbinnssmith]

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]

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]

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. :smile:

[mk-pmb]

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.