search for: openfileforwrit

...iew the granularity of the interface because it +is likely you're trying to implement something that is too low level. The rule +of thumb is to provide interface functions that **can't** fail, except when +faced with hard errors. + +For a trivial example, suppose we wanted to add an "``OpenFileForWriting``" +function. For many operating systems, if the file doesn't exist, attempting to +open the file will produce an error. However, ``lib/Support`` should not simply +throw that error if it occurs because its a soft error. The problem is that the +interface function, ``OpenFileForWriting...

...it >> +is likely you're trying to implement something that is too low level. The rule >> +of thumb is to provide interface functions that **can't** fail, except when >> +faced with hard errors. >> + >> +For a trivial example, suppose we wanted to add an "``OpenFileForWriting``" >> +function. For many operating systems, if the file doesn't exist, attempting to >> +open the file will produce an error. However, ``lib/Support`` should >> not simply >> +throw that error if it occurs because its a soft error. The problem is that the >&...

...e interface because it > +is likely you're trying to implement something that is too low level. The rule > +of thumb is to provide interface functions that **can't** fail, except when > +faced with hard errors. > + > +For a trivial example, suppose we wanted to add an "``OpenFileForWriting``" > +function. For many operating systems, if the file doesn't exist, attempting to > +open the file will produce an error. However, ``lib/Support`` should > not simply > +throw that error if it occurs because its a soft error. The problem is that the > +interface funct...

...can affect the granularity and the nature of the interface. In general, if you find that you're wanting to throw soft errors, you must review the granularity of the interface because it @@ -171,13 +171,13 @@ faced with hard errors. For a trivial example, suppose we wanted to add an "``OpenFileForWriting``" function. For many operating systems, if the file doesn't exist, attempting to -open the file will produce an error. However, ``lib/System`` should not simply +open the file will produce an error. However, ``lib/Support`` should not simply throw that error if it occurs because it...

On 25 May 2013 15:30, Sean Silva <silvas at purdue.edu> wrote: > This will break existing URLs. Until we have a way to set up redirects the > file name should stay the same. Would a SystemLibrary.rst saying it was replaced with the support library be ok? > -- Sean Silva Cheers, Rafael

...he nature of the interface. In general, if you find that you're > wanting to > throw soft errors, you must review the granularity of the interface > because it > @@ -171,13 +171,13 @@ faced with hard errors. > > For a trivial example, suppose we wanted to add an > "``OpenFileForWriting``" > function. For many operating systems, if the file doesn't exist, > attempting to > -open the file will produce an error. However, ``lib/System`` should not > simply > +open the file will produce an error. However, ``lib/Support`` should > not simply > throw...

Currently a power failure or other hard crash can cause lld leave a temporary file around. The same is true for other llvm tools. As an example, put a breakpoint in Writer.cpp:236 ("writeBuildId()") and restart the run a few times. You will get t.tmp43a735a t.tmp4deeabb t.tmp9bacdd3 t.tmpe4115c4 t.tmpeb01fff The same would happen if there was a fatal error between the