Jira (PUP-10213) Do not create exceptions for stacktrace information when we know we won't use that information

17 views
Skip to first unread message

Justin Stoller (JIRA)

unread,
Jan 2, 2020, 4:24:03 PM1/2/20
to puppe...@googlegroups.com
Justin Stoller created an issue
 
Puppet / Improvement PUP-10213
Do not create exceptions for stacktrace information when we know we won't use that information
Issue Type: Improvement Improvement
Assignee: Unassigned
Created: 2020/01/02 1:23 PM
Priority: Normal Normal
Reporter: Justin Stoller

Currently when the evaluator runs across a valid warning it will create an exception in the `optionally_fail` method. That exception is passed into the error handling code (acceptor) that later decides if the issue warrants erring out, printing a warning with a stacktrace, printing a warning without a stacktrace, or ignoring.

Creating exceptions/backtraces are expensive in some environments, we should only create them when we know we will print the information they contain. There is no use in creating them when we know we will not use them.

It should be possible to check the validator/acceptor from optionally_fail and only create the exception when the correct conditions hold.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Justin Stoller (JIRA)

unread,
Jan 2, 2020, 4:24:03 PM1/2/20
to puppe...@googlegroups.com

Maggie Dreyer (JIRA)

unread,
Jan 2, 2020, 6:27:04 PM1/2/20
to puppe...@googlegroups.com

Justin Stoller (JIRA)

unread,
Jan 6, 2020, 7:04:04 PM1/6/20
to puppe...@googlegroups.com
Justin Stoller updated an issue
Change By: Justin Stoller
Release Notes Summary: Some compilation warnings will now take less time to compute.
Release Notes: Enhancement

Justin Stoller (JIRA)

unread,
Jan 6, 2020, 7:05:03 PM1/6/20
to puppe...@googlegroups.com
Justin Stoller updated an issue
Change By: Justin Stoller
Fix Version/s: PUP 6.12.0
Fix Version/s: PUP 6.4.5
Fix Version/s: PUP 5.5.18

Josh Cooper (JIRA)

unread,
Jan 7, 2020, 5:07:04 PM1/7/20
to puppe...@googlegroups.com

Josh Cooper (JIRA)

unread,
Jan 7, 2020, 5:08:05 PM1/7/20
to puppe...@googlegroups.com

Jean Bond (JIRA)

unread,
Jan 8, 2020, 3:00:03 PM1/8/20
to puppe...@googlegroups.com
Jean Bond updated an issue
 
Change By: Jean Bond
Release Notes Summary: Some This release includes improvements to the evaluator, meaning some compilation warnings will now take less time to compute.

Josh Cooper (JIRA)

unread,
Jan 9, 2020, 2:55:04 PM1/9/20
to puppe...@googlegroups.com

Kate Medred (JIRA)

unread,
Jan 10, 2020, 6:25:04 PM1/10/20
to puppe...@googlegroups.com
Kate Medred updated an issue
 
Change By: Kate Medred
Release note: Do not create exceptions for stacktrace information

Currently , when the evaluator runs across a valid warning it will create an exception in the optionally_fail method. That exception is passed into the error handling code (acceptor) that later decides if the issue warrants erring out, printing a warning with a stacktrace, printing a warning without a stacktrace, or ignoring. There is no use in creating exceptions when it is known they will not be used. It should be possible to check the validator/acceptor from optionally_fail and only create the exception when the correct conditions hold.

------

Original note: Currently when the evaluator runs across a valid warning it will create an exception in the
`optionally_fail` method. That exception is passed into the error handling code (acceptor) that later decides if the issue warrants erring out, printing a warning with a stacktrace, printing a warning without a stacktrace, or ignoring.


Creating exceptions/backtraces are expensive in some environments, we should only create them when we know we will print the information they contain. There is no use in creating them when we know we will not use them.

It should be possible to check the validator/acceptor from optionally_fail and only create the exception when the correct conditions hold.
Reply all
Reply to author
Forward
0 new messages