Bug 233178 - FreeBSD 12.0-BETA - bectl create NEWBE - multiple error messages instead of one
Summary: FreeBSD 12.0-BETA - bectl create NEWBE - multiple error messages instead of one
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: Kyle Evans
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2018-11-12 19:29 UTC by vermaden
Modified: 2019-03-19 18:53 UTC (History)
3 users (show)

See Also:


Attachments
only call set_error() when an error is first encountered. (7.53 KB, patch)
2018-11-14 19:26 UTC, Rob
rob.fx907: maintainer-approval?
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description vermaden 2018-11-12 19:29:39 UTC
Currently:

# bectl create ZFSBE
boot environment name already taken
boot environment name already taken
boot environment name already taken
boot environment name already taken
failed to create bootenv ZFSBE
# 

Can/should be:

# bectl create ZFSBE
boot environment ZFSBE already exists
#
Comment 1 Rob 2018-11-14 19:26:14 UTC
Created attachment 199243 [details]
only call set_error() when an error is first encountered.

set_error() was previously being called multiple times for the same error.

This patch calls set_error() only when the type of error is known first-hand. Once the error number is set, the error number is returned up the chain.

While this patch is by no means a robust fix, it does start to address the core issue this bug originates from - which is inconsistent error handling within libbe. What I mean by inconsistency is that, some routines within libbe return an error number (without using set_error()) while other functions use set_error() and then return an error number. 

Hopefully this patch will be considered as a first-step to bringing consistent error handling within libbe. An error should be set once, as soon as its known, and the associated error number should be returned up the chain - eventually making it's way to an application program, presumably. 

The diff was taken from r340424 (HEAD), should it be against stable/12 branch? This is my first patch submission, so bear with me.
Comment 2 Kyle Evans freebsd_committer 2019-03-19 18:53:44 UTC
Take.