Re^2: Perl Best Practices

There is at least one very good use of goto in C: error handling.

In a function that allocates and initializes complex structures, an earlier allocation can succeed but a later allocation fail. When this happens, the earlier allocation must be released before returning NULL to avoid leaking memory.

something *
alloc_something(void)
{
  something * ret = malloc(sizeof(something));
  if (ret == NULL) goto out;

  ret->another_thing = alloc_another_thing();
  if (ret->another_thing == NULL) goto out_free_ret;

  return ret;

  /* error exits */
  out_free_ret:
  free(ret);
  out:
  return NULL;
}
[download]

I learned this style from reading Linux kernel sources and it makes error handling much more readable and maintainable by keeping the successful path and the error path separate. While this example was very simple, this pattern especially shines when more than one allocation must be backed out before returning failure because it avoids duplicating the code to release the earlier allocations.

Comment on Re^2: Perl Best Practices - Loop Labels Select or Download Code

Replies are listed 'Best First'.
Re^3: Perl Best Practices - Loop Labels by talexb (Chancellor) on Apr 19, 2020 at 19:41 UTC
Interesting .. yet I can see a fairly simple way to restructure this C code, without either of the `goto` statements .. something * alloc_something(void) { /* Make two malloc requests. Insure both succeed; return allocated memory, if any. Three possible logic paths: 1. First malloc fails, and we are done. 2. First malloc succeeds, second malloc fails: free the first allocated block, and we are done. 3. First and second mallocs succeed, and we are done. / something ret = malloc(sizeof(something)); /* Did the first request succeed? / if (ret != NULL) { ret->another_thing = alloc_another_thing(); / Did the second request fail? */ if (ret->another_thing == NULL) { free(ret); ret = NULL; } } return ret; } [download] Alex / talexb / Toronto Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.	[reply] [d/l] [select]
Re^4: Perl Best Practices - Loop Labels by jcb (Parson) on Apr 20, 2020 at 03:34 UTC
Yes, and that was the pattern I used before finding the "`goto out`" pattern in the Linux kernel sources. For simple cases, there is little difference, but even with two allocations, a problem begins to appear: compare the indentation depth between the two solutions and consider what happens when they are extended to include a third or fourth allocation. The "`goto out`" pattern also takes up far less vertical space for error handling in the main code path, like the common `open ... or die ...` idiom in Perl. When the error path is also branchless, simply releasing some subset of allocated objects and returning NULL, the "`goto out`" pattern has the advantage of cleanly grouping the error path into one block (with many entry points) after the main code path, allowing both to be examined separately. I should probably include a reminder here that this pattern is useful in C, but Perl has better ways of handling error exits because the runtime manages memory, unlike in C. I am unsure if I have ever used `goto LABEL` in Perl.	[reply] [d/l] [select]


go ahead... be a heretic
	PerlMonks

Re^2: Perl Best Practices - Loop Labels