> On Feb 21, 2021, at 8:51 PM, Ian Davis <m...@iandavis.com> wrote:
>
> On Sun, 21 Feb 2021, at 5:23 PM, robert engels wrote:
>> Can someone please explain the benefit of ‘error return’ over ‘checked
>> exceptions’ ? I have made the point a few times and it goes to crickets
>> - I have to believe that is because there is none, or it is difficult
>> to communicate.
>>
>
> I think since this is a Go list, the onus is on advocates of exceptions to
> demonstrate the benefit of checked exceptions over error return values.
>
> Here are a couple of scenarios that I encountered recently that had logical
> linear flow with error returns. I'm curious how they would be improved with
> checked exceptions:
>
> 1) open three files for writing, closing the earlier ones if a subsequent one
> fails to open
>
The requests are a little basic and lead to trivial solutions, like this:
public static void writeFiles() throws IOException {
try(FileOutputStream f1 = new FileOutputStream("file1");
FileOutputStream f2 = new FileOutputStream("file2");
FileOutputStream f3 = new FileOutputStream("file3")
) {
// at this point all files are open for writing and ready to be
processed
// if any open failed, the other files are closed
}
}
> 2) open a file for append, falling back to creating a new writeable file if
> the original is read-only or doesn't exist. The new file creation may also
> fail due to disk errors or permissions.
>
Technically, this is just as trivial because of the way the stdlib implements
this:
public static void openFile() throws IOException {
try(FileOutputStream f1 = new FileOutputStream("somefile",true);
) {
// at this the file is open for writing and will be closed when the
block/method exits
}
}
But lets assume that method failed if 'open for append' failed if the file
didn’t exist:
class Test {
private static FileOutputStream openAppendOrCreate(String name) throws
FileNotFoundException {
try {
return new FileOutputStream(name,true);
} catch(FileNotFoundException e){
return new FileOutputStream(name);
}
}
public static void openFile() throws IOException {
try(FileOutputStream f1 = openAppendOrCreate("somefile");
) {
// at this the file is open for writing and will be closed when the
block exits
}
}
}
Still, in a significant system and this being a core operation I wouldn’t rely
on so much stdlib convenience/behavior and would instead use more low-level
methods that take a File, checking for existence and writability, etc. but the
basic pattern of wrapping ‘resource creation’ into a method to improve
readability and keep the try-with-resource blocks simple.
If you need to delete a file in addition to closing when the block exits you
are better off using a ‘resource creation’ method that creates a wrapper stream
that deletes on close. Or you could use the various ‘create temp’ file methods
and ‘delete on exit’ and let the platform handle the clean-up.
> I can envisage how to write them with exceptions but I'm struggling to see
> where it would be more succinct or easier to read.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9f3cf023-5bb4-49da-a842-0be97904d21a%40www.fastmail.com.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/41BAFD5D-F6A9-4069-8B36-7BD2C85D9D3B%40ix.netcom.com.
