├── error-design-patterns-book ├── src │ ├── 5_ffi │ │ └── ffi.md │ ├── 2_idioms │ │ └── idioms.md │ ├── 0_summary │ │ └── summary.md │ ├── 7_appendix │ │ ├── b_safety.md │ │ ├── a_error_libs.md │ │ └── c_references.md │ ├── 1_general │ │ └── error_handling.md │ ├── 6_glossary │ │ └── glossary.md │ ├── 4_anti-patterns │ │ └── anti-patterns.md │ ├── 3_design_patterns │ │ └── design_patterns.md │ └── SUMMARY.md ├── Crichton - 2020 - The Usability of Ownership.pdf ├── Narayanan et al. - RedLeaf Isolation and Communication in a Safe Ope.pdf ├── Costa et al. - 2021 - Breaking Type Safety in Go An Empirical Study on .pdf ├── Finkbeiner et al. - 2020 - Verified Rust Monitors for Lola Specifications.pdf ├── Jahangirova et al. - 2020 - An Empirical Study on Failed Error Propagation in .pdf ├── book.toml └── collect-references-here ├── .gitignore ├── meetings ├── README.md ├── 2021-04-26.md ├── 2021-04-12.md ├── 2020-11-23.md ├── 2021-03-01.md ├── 2021-02-01.md ├── 2021-01-18.md ├── 2021-03-15.md ├── 2021-02-15.md ├── 2020-09-28.md ├── 2020-12-07.md ├── 2020-10-12.md ├── 2020-10-26.md └── 2020-11-09.md ├── CODE_OF_CONDUCT.md ├── SUMMARY.md ├── draft-rfcs ├── README.md └── error-reporter-rfc-template.md ├── .github └── workflows │ ├── deploy_mdbook.yml.disabled │ └── check_graphviz_source.yml ├── REVIEWTOMERGE-project-board-updates ├── LICENSE-MIT ├── error-handling.gv ├── README.md ├── CHARTER.md └── LICENSE-APACHE /error-design-patterns-book/src/5_ffi/ffi.md: -------------------------------------------------------------------------------- 1 | # FFI 2 | -------------------------------------------------------------------------------- /error-design-patterns-book/src/2_idioms/idioms.md: -------------------------------------------------------------------------------- 1 | # Idioms 2 | -------------------------------------------------------------------------------- /error-design-patterns-book/src/0_summary/summary.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *~ 2 | ./ 3 | .gitignore 4 | error-design-patterns-book/books -------------------------------------------------------------------------------- /error-design-patterns-book/src/7_appendix/b_safety.md: -------------------------------------------------------------------------------- 1 | # B - Safety 2 | -------------------------------------------------------------------------------- /error-design-patterns-book/src/1_general/error_handling.md: -------------------------------------------------------------------------------- 1 | # Generalities 2 | -------------------------------------------------------------------------------- /error-design-patterns-book/src/6_glossary/glossary.md: -------------------------------------------------------------------------------- 1 | # Terms Reference 2 | -------------------------------------------------------------------------------- /error-design-patterns-book/src/7_appendix/a_error_libs.md: -------------------------------------------------------------------------------- 1 | # A - Error Libs 2 | -------------------------------------------------------------------------------- /error-design-patterns-book/src/7_appendix/c_references.md: -------------------------------------------------------------------------------- 1 | # C - References 2 | -------------------------------------------------------------------------------- /error-design-patterns-book/src/4_anti-patterns/anti-patterns.md: -------------------------------------------------------------------------------- 1 | # Anti-Patterns 2 | -------------------------------------------------------------------------------- /error-design-patterns-book/src/3_design_patterns/design_patterns.md: -------------------------------------------------------------------------------- 1 | # Design Patterns 2 | -------------------------------------------------------------------------------- /meetings/README.md: -------------------------------------------------------------------------------- 1 | # Meetings 2 | 3 | This folder contains the minutes of all the recorded meetings that have happened 4 | so far. 5 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # The Rust Code of Conduct 2 | 3 | The Code of Conduct for this repository [can be found 4 | online](https://www.rust-lang.org/conduct.html). 5 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | - [Welcome](./README.md) 4 | - [Charter](./CHARTER.md) 5 | - [Meetings](./meetings/README.md) 6 | - [Draft RFCs](./draft-rfcs/README.md) 7 | -------------------------------------------------------------------------------- /error-design-patterns-book/Crichton - 2020 - The Usability of Ownership.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rust-lang/project-error-handling/HEAD/error-design-patterns-book/Crichton - 2020 - The Usability of Ownership.pdf -------------------------------------------------------------------------------- /error-design-patterns-book/Narayanan et al. - RedLeaf Isolation and Communication in a Safe Ope.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rust-lang/project-error-handling/HEAD/error-design-patterns-book/Narayanan et al. - RedLeaf Isolation and Communication in a Safe Ope.pdf -------------------------------------------------------------------------------- /error-design-patterns-book/Costa et al. - 2021 - Breaking Type Safety in Go An Empirical Study on .pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rust-lang/project-error-handling/HEAD/error-design-patterns-book/Costa et al. - 2021 - Breaking Type Safety in Go An Empirical Study on .pdf -------------------------------------------------------------------------------- /error-design-patterns-book/Finkbeiner et al. - 2020 - Verified Rust Monitors for Lola Specifications.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rust-lang/project-error-handling/HEAD/error-design-patterns-book/Finkbeiner et al. - 2020 - Verified Rust Monitors for Lola Specifications.pdf -------------------------------------------------------------------------------- /error-design-patterns-book/Jahangirova et al. - 2020 - An Empirical Study on Failed Error Propagation in .pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rust-lang/project-error-handling/HEAD/error-design-patterns-book/Jahangirova et al. - 2020 - An Empirical Study on Failed Error Propagation in .pdf -------------------------------------------------------------------------------- /draft-rfcs/README.md: -------------------------------------------------------------------------------- 1 | # RFC drafts 2 | 3 | This folder contains drafts of RFCs that the group is preparing to submit. 4 | 5 | 9 | -------------------------------------------------------------------------------- /.github/workflows/deploy_mdbook.yml.disabled: -------------------------------------------------------------------------------- 1 | on: 2 | push: 3 | branches: 4 | - master 5 | 6 | jobs: 7 | ci: 8 | name: CI 9 | runs-on: ubuntu-latest 10 | steps: 11 | - uses: actions/checkout@v3 12 | - uses: XAMPPRocky/deploy-mdbook@v1 13 | with: 14 | token: ${{ secrets.GITHUB_TOKEN }} 15 | -------------------------------------------------------------------------------- /error-design-patterns-book/book.toml: -------------------------------------------------------------------------------- 1 | [book] 2 | authors = ["Rust Error Handling Project Members"] 3 | language = "en" 4 | multilingual = false 5 | src = "./src" 6 | title = "The Rust Error Book (Title Pending)" 7 | 8 | [rust] 9 | edition = "2018" 10 | 11 | [build] 12 | create-missing = true 13 | 14 | [preprocessor.links] 15 | 16 | [preprocessor.index] 17 | 18 | [output.html] 19 | no-section-label = true 20 | git-repository-url = "https://github.com/rust-lang/project-error-handling" 21 | -------------------------------------------------------------------------------- /REVIEWTOMERGE-project-board-updates: -------------------------------------------------------------------------------- 1 | https://github.com/rust-lang/rust/issues/34472 2 | https://github.com/rust-lang/rust/issues/36749 3 | https://github.com/rust-lang/rust/issues/37179 4 | https://github.com/rust-lang/rust/issues/43354 5 | https://github.com/rust-lang/rust/issues/37634 6 | https://github.com/rust-lang/rust/issues/37871 7 | https://github.com/rust-lang/rust/issues/41407 8 | https://github.com/rust-lang/rust/issues/42154 9 | https://github.com/rust-lang/rust/issues/51588 10 | https://github.com/rust-lang/rust/issues/30974 11 | https://github.com/rust-lang/rust/issues/49129 12 | https://github.com/rust-lang/rust/issues/54144 13 | https://github.com/rust-lang/rust/issues/51125 14 | https://github.com/rust-lang/rust/issues/54889 15 | https://github.com/rust-lang/rust/issues/40322 16 | -------------------------------------------------------------------------------- /error-design-patterns-book/src/SUMMARY.md: -------------------------------------------------------------------------------- 1 | #### Summary 2 | 3 | - [Summary](./0_summary/summary.md) 4 | 5 | #### Generalities of Error Handling 6 | 7 | - [Generalities](./1_general/error_handling.md) 8 | 9 | #### Rust's Idioms for Handling Errors 10 | 11 | - [Idioms](./2_idioms/idioms.md) 12 | 13 | #### Advanced Error Design Patterns 14 | 15 | - [Design Patterns](./3_design_patterns/design_patterns.md) 16 | 17 | #### Error Anti-Patterns 18 | 19 | - [Anti-Patterns](./4_anti-patterns/anti-patterns.md) 20 | 21 | #### FFI 22 | 23 | - [FFI](./5_ffi/ffi.md) 24 | 25 | #### Glossary 26 | 27 | - [Terms Reference](./6_glossary/glossary.md) 28 | 29 | #### Appendices/Additional Resources 30 | 31 | - [A - Error Libs](./7_appendix/a_error_libs.md) 32 | - [B - Safety](./7_appendix/b_safety.md) 33 | - [C - References](./7_appendix/c_references.md) 34 | -------------------------------------------------------------------------------- /LICENSE-MIT: -------------------------------------------------------------------------------- 1 | Permission is hereby granted, free of charge, to any 2 | person obtaining a copy of this software and associated 3 | documentation files (the "Software"), to deal in the 4 | Software without restriction, including without 5 | limitation the rights to use, copy, modify, merge, 6 | publish, distribute, sublicense, and/or sell copies of 7 | the Software, and to permit persons to whom the Software 8 | is furnished to do so, subject to the following 9 | conditions: 10 | 11 | The above copyright notice and this permission notice 12 | shall be included in all copies or substantial portions 13 | of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF 16 | ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 17 | TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A 18 | PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 19 | SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY 20 | CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION 21 | OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR 22 | IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 23 | DEALINGS IN THE SOFTWARE. 24 | -------------------------------------------------------------------------------- /meetings/2021-04-26.md: -------------------------------------------------------------------------------- 1 | # PEH 2021-04-26 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - Previous Meeting: https://github.com/rust-lang/project-error-handling/blob/master/meetings/2021-04-12.md 6 | - Action Items: https://hackmd.io/@rust-libs/Hyj7kRSld 7 | - Book Planning Doc: https://cryptpad.fr/code/#/2/code/edit/1FhyaBOOANgdSTKA8xbYIt8t/ 8 | 9 | ## Agenda Items 10 | 11 | - Review action items from last meeting 12 | - Review [Project Board](https://github.com/rust-lang/project-error-handling/projects/1) Issues 13 | - Individual Status Updates 14 | 15 | # Attendees 16 | 17 | - Jane Lusby 18 | - oliver 19 | - Jakub Duchniewicz 20 | - Charles Ellis O'Riley Jr. 21 | - Senyo Simpson 22 | 23 | # Meeting Minutes 24 | 25 | ## Resolved Action Items 26 | 27 | - created tracking issue for book work 28 | - summarized 3rd party library in book discussion 29 | - Paused book meetings until we have more bandwidth to work on it 30 | - Plecra is working on a new RFC on the downcasting logic from the generic member access RFC 31 | - Updated generic member access RFC to use new dyno API 32 | - Updated tracking issue for fixing the error trait 33 | - found possible solution to soundness issue for specializing Termination 34 | - Nearly done with blog post for future work related to lost context 35 | - Chas is now porting the diagram for the book to dot 36 | 37 | -------------------------------------------------------------------------------- /.github/workflows/check_graphviz_source.yml: -------------------------------------------------------------------------------- 1 | # name: check-graphviz-file 2 | # ts-graphviz/setup-graphviz@v1 : https://github.com/ts-graphviz/setup-graphviz 3 | # tj-actions/changed-files@v9 : https://github.com/tj-actions/changed-files 4 | # Trigger the workflow on [pull_request, push] 5 | # but only for the main/master branch 6 | on: 7 | pull_request: 8 | branches: [ master ] 9 | push: 10 | branches: [ master] 11 | 12 | jobs: 13 | check-graphviz-file: 14 | runs-on: ubuntu-latest 15 | 16 | steps: 17 | - uses: actions/checkout@v3 18 | with: 19 | fetch-depth: 0 20 | 21 | - uses: ts-graphviz/setup-graphviz@v1 22 | 23 | - name: Get specific changed file(s) 24 | id: changed-files-specific 25 | uses: tj-actions/changed-files@v9 26 | with : 27 | files: | 28 | error-handling.gv 29 | 30 | - name: Create svg if the listed file changed 31 | if: steps.changed-files-specific.outputs.only_changed == 'true' 32 | run: | 33 | dot -Tsvg error-handling.gv > error-handling.svg 34 | 35 | - name: 'Upload Artifact if the listed file changed' 36 | if: steps.changed-files-specific.outputs.only_changed == 'true' 37 | uses: actions/upload-artifact@v2 38 | with: 39 | name: error-handling 40 | path: error-handling.svg 41 | retention-days: 30 -------------------------------------------------------------------------------- /meetings/2021-04-12.md: -------------------------------------------------------------------------------- 1 | # PEH 2021-04-12 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - Previous Meeting: https://github.com/rust-lang/project-error-handling/blob/master/meetings/2021-03-15.md 6 | - Action Items: https://hackmd.io/@rust-libs/Hyj7kRSld 7 | - Book Planning Doc: https://cryptpad.fr/code/#/2/code/edit/1FhyaBOOANgdSTKA8xbYIt8t/ 8 | 9 | ## Agenda Items 10 | 11 | - Review action items from last meeting 12 | - Individual Status Updates 13 | - Review [Project Board](https://github.com/rust-lang/project-error-handling/projects/1) Issues 14 | - https://github.com/rust-lang/rust/issues/46871 15 | - https://github.com/rust-lang/rust/pull/79692 16 | - https://github.com/rust-lang/compiler-team/issues/410 17 | - https://users.rust-lang.org/t/an-essay-of-checked-exceptions-in-rust/57769 18 | - https://users.rust-lang.org/t/using-the-return-operator-in-the-match-expression-early-return-of-an-error/58025 19 | 20 | # Attendees 21 | 22 | - Jane Lusby 23 | - Jakub Duchniewicz 24 | - Charles (Chas) Ellis O'Riley Jr. 25 | 26 | # Meeting Minutes (Jane) 27 | 28 | ## Action Items Review 29 | 30 | - blog post is currently waiting on feedback from Niko, meeting scheduled to discuss it on Friday, will probably need another revision after that conversation. 31 | - Error diagram for book is coming along 32 | - Termination trait has run into issues with specialization, also need to answer questions about the underlying representation. 33 | - backtrace in core is having issues with lang items not being recognized, even for the initial PoC impl 34 | - Generic member access RFC update is in progress, splitting type tagged downcasting into it's own RFC 35 | 36 | ## Issue Triage 37 | 38 | - Why doesn't NoneError impl Error? 39 | - need to review the thread, but general feeling is NoneError isn't representitive of an actual error and so shouldn't exist 40 | - added to project board to track the issue 41 | - automatic filtering of query machinery out of backtraces 42 | - Looks awesome, no involvement needed from PG-Error-Handling 43 | - Essay on checked exceptions 44 | - Nice user story, will keep monitoring but no action needed from PG-Error-Handling 45 | 46 | -------------------------------------------------------------------------------- /meetings/2020-11-23.md: -------------------------------------------------------------------------------- 1 | # PEH 2020-11-23 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - [2020-11-09 Meeting Minutes](https://github.com/rust-lang/project-error-handling/blob/master/meetings/2020-11-09.md) 6 | 7 | ## Action Items 8 | 9 | - Implement trait based proof of concept for `Backtrace` in `core` (Jane Lusby) 10 | - Update `object-provider` API in generic member access RFC (Jane Lusby) 11 | - Fix regressions caused by new impl error for `&'a E` change (unassigned) 12 | - Review the "Fix the error trait" tracking issue to figure out next steps 13 | (Oliver + Ashley Mannix) 14 | - Review the panic plan rfc (Jane Lusby) 15 | - reach out to the author of the error codes issue (Jane Lusby) 16 | - Get long-term blog post posted on Inside Rust blog (Sean Chen) 17 | - Resolve blockers in the backtrace stabilizition PR (Ashley Mannix) 18 | - Follow up with Amanieu to mark concerns on backtrace stabilization as resolved 19 | (Ashley Mannix) 20 | - Create an issue and gather resources to use as reference material for the Rust 21 | Error Book (Jane Lusby) 22 | - Review open issues related to Error Handling and collate (Oliver) 23 | 24 | ## Agenda Items 25 | 26 | - Review action items from last meeting 27 | 28 | # Attendees 29 | - Sean Chen 30 | - Jane Lusby 31 | - oliver :snowman: 32 | - Jeremiah Senkpiel 33 | - simulacrum 34 | - Ashley Mannix 35 | - Charles Ellis O'Riley Jr. 36 | 37 | # Meeting Minutes 38 | 39 | - Work continues on nicer assert messages (Charles O.) 40 | - [Stabilize the backtrace feature.](https://github.com/rust-lang/rust/pull/72981) (Jeremiah S. & Ashley M.) 41 | - past final comments stage 42 | - stabilization has been unblocked 43 | - Blog Post (Sean C.) 44 | - ready to merge! 45 | - 'Fix the error trait' update (Oliver D. & Ashley M.) 46 | - posted and edited the tracking and related issues on GH (Ashley M.) 47 | - no forward momentum _but_ the activity on the issue was noticed and well 48 | received by a decent number of accounts on GH 49 | - next step is to push forward and continue capturing the attention of 50 | possible contributors as is most appropriate 51 | - currently no obvious blockers 52 | -------------------------------------------------------------------------------- /error-handling.gv: -------------------------------------------------------------------------------- 1 | digraph g { 2 | graph [ 3 | rankdir = "LR"; 4 | // title 5 | labelloc= "t"; 6 | label= <Error Handling>; 7 | ]; 8 | 9 | node [ 10 | fontsize = "13" 11 | shape = "Mrecord" 12 | ]; 13 | 14 | T [ 15 | label = "< T >" 16 | shape = plain 17 | fontsize=9 18 | id = 0 19 | ]; 20 | 21 | Result [ 22 | label = "<<Enum>>\nResult| 23 | + Variant: Ok \l | 24 | + Variant: Err \l" 25 | id = 1 26 | ]; 27 | 28 | Option [ 29 | label = "<<Enum>>\nOption| 30 | + Variant: Some \l | 31 | + Variant: None \l" 32 | id = 2 33 | ]; 34 | 35 | Panic [ 36 | label = " <<Macro>>\nPanic | 37 | + Attribute: #[panic_handler] \l | 38 | + Function: take_hook \l | 39 | + Function: catch_unwind \l | 40 | + Function: resume_unwind \l | 41 | + Function: panic_any \l" 42 | id = 3 43 | ]; 44 | 45 | PanicInfo [ 46 | label = " <<Struct>>\nPanicInfo | 47 | + Function: location \l | 48 | + Function: message \l | 49 | + Function: payload \l" 50 | id = 4 51 | ]; 52 | 53 | // Layout 54 | // T to Option {reverse direction i.e. <-} 55 | {T -> Option:f0 [ 56 | dir=back 57 | label="Some(T)\nunwrap()" 58 | fontsize=8 59 | ]; 60 | } 61 | 62 | Result:f0 -> T [ 63 | label="Ok(T)\nunwrap()" 64 | fontsize=8 65 | ]; 66 | 67 | Result:f1 -> Panic:f0 [ 68 | label="Err(E)\nunwrap()" 69 | fontsize=8 70 | 71 | ]; 72 | 73 | Option:f1 -> Panic:f0:n [ 74 | label="None\nunwrap()" 75 | fontsize=8 76 | ]; 77 | 78 | Panic:f2 -> PanicInfo:f0:n [ 79 | label="set_hook" 80 | fontsize=8 81 | ]; 82 | 83 | Panic:f3 -> PanicInfo:f0 [ 84 | label="<<include>>" 85 | fontsize=8 86 | ]; 87 | 88 | {rank=same; Result Option;} 89 | 90 | } -------------------------------------------------------------------------------- /meetings/2021-03-01.md: -------------------------------------------------------------------------------- 1 | # PEH 2021-03-01 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - Previous Meeting: https://github.com/rust-lang/project-error-handling/blob/master/meetings/2021-02-15.md 6 | - Action Items: https://hackmd.io/@rust-libs/Hyj7kRSld 7 | - Book Planning Doc: https://cryptpad.fr/code/#/2/code/edit/1FhyaBOOANgdSTKA8xbYIt8t/ 8 | 9 | ## Agenda Items 10 | 11 | - Review action items from last meeting 12 | - Individual Status Updates 13 | - Review [Project Board](https://github.com/rust-lang/project-error-handling/projects/1) Issues 14 | - Review [RFC#3084](https://github.com/rust-lang/rfcs/pull/3084) for ongoing project tracking 15 | 16 | # Attendees 17 | - Jane Lusby 18 | - Sean Chen 19 | - Charles Ellis O'Riley Jr. 20 | - Mara 21 | 22 | # Meeting Minutes 23 | 24 | ## Reviewing Action Items 25 | - Jane to start doing some pre-meeting triage of the action items list 26 | - Got the recurring book meeting setup 27 | - Stage the API guidelines changes and have them go live after Jane's blog post is done 28 | - Charles making progress on the Error Book diagram 29 | - Jakub making progress on the termination trait issue 30 | - Sean made no progress on adding `panic_error` to std/core 31 | - Jane to take this one since it's closely related to the blog post she's working on 32 | - Jane will be taking on all action items that involve creating issues 33 | 34 | ## Status Updates 35 | - Jane is approximately 75% done with the blog post 36 | - Updated plan is now: 37 | - 1. move error trait to core 38 | - 2. add `panic_error` function like `panic_any` 39 | - 3. specialize `unwrap` and `expect` to use `panic_error` 40 | - 4. add a reporting mechanism to either the error trait or to the `fmt` grammar for printing errors as a report including source error messages 41 | - 5. Introduce a `Box` equivalent that implement's Error and not `From` 42 | - 6. Add an alternative Result type that uses `FromResidual` to convert error types during `?` 43 | - 7. Add lints to discourage usage of `Box` 44 | - Charles is working on the Error Book diagram 45 | - Jakub is working on the termination trait issue 46 | - Sean is working on writing the content around the `minigrep` project example for the Error Book 47 | 48 | ## Reviewing Open Issues 49 | 50 | - Currently sitting on [https://github.com/rust-lang/rfcs/pull/3084](https://github.com/rust-lang/rfcs/pull/3084); waiting for more feedback from the Rust community before we decide how to move forward with it -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Error Handling Project Group 2 | 3 | Welcome to the repository for the Error Handling Project Group! We're focused on 4 | defining and communicating Rust's error handling story. 5 | 6 | This is the repository we use to organise our work. Please refer to our 7 | [charter] for more information on our goals and current scope. 8 | 9 | - Shepherds: 10 | - [Jane Lusby (yaahc)](https://github.com/yaahc) 11 | - [Sean Chen (seanchen1991)](https://github.com/seanchen1991) 12 | - Rust library team contact: 13 | - [Mara Bos (m-ou-se)](https://github.com/m-ou-se) 14 | - Advisors: 15 | - [Andrew Gallant (BurntSushi)](https://github.com/burntsushi) 16 | 17 | [charter]: ./CHARTER.md 18 | 19 | ## How do I follow the project group's work? 20 | 21 | The best place to start is probably the agenda of the next meeting. This is 22 | where we track action items from the previous meeting, the previous meetings 23 | agenda and minutes, and upcoming topics for the next meeting. You can also check 24 | out our issue tracker, project boards, and zulip chat to see all of the pieces 25 | of work that we're doing. 26 | 27 | - [Upcoming Meeting Agenda][active-agenda] 28 | - [Libs Team Tracked Issues][libs-error-project-tab] 29 | - [Project Group Tracked Issues][upstream-work-project-board] 30 | - [Project Group Repo Issues][open issues] 31 | - [Project Group Zulip Stream][chat-link] 32 | 33 | ## How Can I Get Involved? 34 | 35 | Participation in this project group is open to all. You can see our work in 36 | progress via our [open issues] on this repository and you can participate in 37 | discussions via our [Zulip stream][chat-link] and or introduce yourself in the 38 | [new members thread][members-thread]. We primarily coordinate via our meetings, 39 | which are tracked [here][meeting-schedule]. If you're interested in attending 40 | our meetings but can't due to a schedule conflist please let us know on the 41 | [scheduling issue] so we can best accommodate everyone. 42 | 43 | 44 | [open issues]: ../../issues 45 | [scheduling issue]: ../../issues/2 46 | [chat-link]: https://rust-lang.zulipchat.com/#narrow/stream/257204-project-error-handling 47 | [meeting-schedule]: https://calendar.google.com/calendar/u/0/embed?src=9kuu8evq4eh6uacm262k0phri8@group.calendar.google.com 48 | [active-agenda]: https://hackmd.io/@rust-libs/SkPmShkLD 49 | [libs-error-project-tab]: https://github.com/rust-lang/libs-team/projects/2#column-10224181 50 | [upstream-work-project-board]: https://github.com/rust-lang/project-error-handling/projects/1 51 | [members-thread]: https://rust-lang.zulipchat.com/#narrow/stream/257204-project-error-handling/topic/New.20Members 52 | -------------------------------------------------------------------------------- /meetings/2021-02-01.md: -------------------------------------------------------------------------------- 1 | # PEH 2021-02-01 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - Previous Meeting: [2021-01-18 Meeting Minutes](https://github.com/rust-lang/project-error-handling/blob/master/meetings/2021-01-18.md) 6 | - Action Items: https://hackmd.io/@rust-libs/Hyj7kRSld 7 | 8 | ## Agenda Items 9 | 10 | - Review action items from last meeting 11 | - Individual Status Updates 12 | - Review [Project Board](https://github.com/rust-lang/project-error-handling/projects/1) Issues 13 | - https://github.com/rust-lang/rust/pull/80851 14 | - https://github.com/rust-lang/rfcs/pull/3058 15 | 16 | # Attendees 17 | - Jane Lusby 18 | - Sean Chen 19 | - Charles Ellis O'Riley Jr. 20 | - oliver 21 | - Jakub Duchniewicz 22 | 23 | # Meeting Minutes 24 | 25 | - Action items have been moved into a separate [document][action-items-doc]. 26 | - [Fixing the error trait][fix-error-trait] seems to have fallen off the radar, perhaps because no one is available to lead it. 27 | - No progress on addressing the error in `rust-sv`. 28 | - No follow up on blog metrics. 29 | - Adding Backtrace to `core` had lots of discussion (i.e. suggestions on implementation approaches), though no implementation progress yet. 30 | - Discussion with the Libs team re. the `Error` trait led to a consensus that the primary role of the trait is for formatting, not downcasting; decided on a guidance for source vs. display. 31 | - Green light on changes to make error formatting more consistent. 32 | - Adding a `panic_error` function similar to `panic_any` (though this might depend on moving the `Error` trait to `core`). 33 | - No progress made on brainstorming topics for the `Error` book 34 | - Setup a Doodle to figure out what time works for those who are interested in attending a brainstorming session. 35 | - [Termination trait][termination-trait] seems to be waiting on generic member access. 36 | - Also needs more design work re. how the final version of `Termination` should look. 37 | - No progress on object provider. 38 | - No follow up on error codes 39 | - Hold off on this until more progress has been made on the `Termination` trait. 40 | - Drop the "better assert messages" issue since someone more knowledgable about it has decided to pick it up. 41 | - [Backtrace frames][backtrace-frames] PR is ready to be merged. 42 | - Progress made on the [2021 panic][2021-panic] implementation, though we aren't explicitly tracking this issue as it's being directly implemented by Mara on the Libs team. 43 | - Proposal for an `Issue Triage` thread dedicated to sorting issues under the group's purview as soon as they're found. 44 | - Figure out how to use `@triagebot` to help stay on top of issues. 45 | 46 | 47 | [action-items-doc]: https://hackmd.io/@rust-libs/Hyj7kRSld 48 | [fix-error-trait]: https://github.com/rust-lang/rust/issues/53487 49 | [termination-trait]: https://github.com/rust-lang/rust/issues/43301 50 | [backtrace-frames]: https://github.com/rust-lang/rust/pull/81022 51 | [2021-panic]: https://github.com/rust-lang/rust/pull/80851 -------------------------------------------------------------------------------- /meetings/2021-01-18.md: -------------------------------------------------------------------------------- 1 | # PEH 2021-01-18 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - [2020-12-07 Meeting Minutes](https://github.com/rust-lang/project-error-handling/blob/master/meetings/2020-12-07.md) 6 | 7 | ## Action Items 8 | 9 | - Figure out what metrics we get on the blog posts we publish (Jane Lusby) 10 | - [[rust-lang/rfcs#2895]](https://github.com/rust-lang/rfcs/pull/2895) Update `object-provider` API in generic member access RFC to utilize new `dyno` design (Jane Lusby) 11 | - [[rust-lang/rust#53487]](https://github.com/rust-lang/rust/issues/53487) Get this PR reviewed and ready to close, find someone to handle mentorship (Jane) 12 | - [[rust-lang/rust#77384]](https://github.com/rust-lang/rust/pull/77384) Implement trait based proof of concept for `Backtrace` in `core` (Jane Lusby) 13 | - [[rust-lang/project-error-handling#7]](https://github.com/rust-lang/project-error-handling/issues/7) reach out to the author of the error codes issue (Jane Lusby) 14 | - [[rust-lang/rust#75180]](https://github.com/rust-lang/rust/pull/75180) Fix regressions caused by new impl error for `&'a E` change (Jakub Duchniewicz) 15 | - [[rust-lang/rust#44838]](https://github.com/rust-lang/rust/issues/44838) Better assert implementation, dig more into AST to figure out steps forward (Charles Ellis O'Riley Jr.) 16 | - [[rust-lang/rust#72981]](https://github.com/rust-lang/rust/pull/72981) 17 | - Resolve blockers in the backtrace stabilizition PR (Ashley Mannix) 18 | - Follow up with Amanieu to mark concerns on backtrace stabilization as resolved (Ashley Mannix) 19 | - Update backtrace PR to resolve merge conflicts (Jakub Duchniewicz) 20 | - https://github.com/rust-lang/rust/pull/79692 (Ashley Mannix) 21 | - [[error handling project group update blog]](https://hackmd.io/GMLcORX_R7W4de0ZryDIxg?view) solicit outside feedback on blog post and publish it (Sean Chen) 22 | 23 | ## Agenda Items 24 | 25 | - Review action items from last meeting 26 | - Review [Project Board](https://github.com/rust-lang/project-error-handling/projects/1) Issues 27 | 28 | # Attendees 29 | 30 | - Jane Lusby 31 | - oliver 32 | - Charles Ellis O'Riley Jr. 33 | - Sean Chen 34 | - Jakub Duchniewicz 35 | 36 | # Meeting Minutes 37 | 38 | ## Status Updates 39 | - Generic Member Access RFC [Jane]: No updates here 40 | - Assert implementation [Charles]: No updates here 41 | - Regression cleanup [Jakub]: Blocked on an error in the `rust-sv` crate 42 | - Updated `catch_unwind`'s documentation to refer to `resume_unwind` 43 | - Implement `Try` for `ExitStatus` [scottmcm]: Blocked on the new `Try` trait RFC 44 | - Termination trait [issue](https://github.com/rust-lang/rust/issues/43301#issuecomment-761900006) added to the project board 45 | - Implementing `Display` and `Error::source` for library errors [issue](https://github.com/rust-lang/project-error-handling/issues/27) added 46 | 47 | ## Todos 48 | - Look into the error in the `rust-sv` crate [Jane] 49 | - Get in touch with the Infrastructure team in order to gather metrics on engagement around the PEH blog post 50 | - Dig deeper into the Backtrace in core PR [oliver] 51 | - Start drafting sections of the book [Jane and oliver] 52 | - Set up a hack session around brainstorming/drafting for the Error book [Jane] 53 | - Look into the Termination trait polishing [issue](https://github.com/rust-lang/rust/issues/43301#issuecomment-761900006): [Jakub] 54 | -------------------------------------------------------------------------------- /meetings/2021-03-15.md: -------------------------------------------------------------------------------- 1 | # PEH 2021-03-15 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - Previous Meeting: https://github.com/rust-lang/project-error-handling/blob/master/meetings/2021-03-01.md 6 | - Action Items: https://hackmd.io/@rust-libs/Hyj7kRSld 7 | - Book Planning Doc: https://cryptpad.fr/code/#/2/code/edit/1FhyaBOOANgdSTKA8xbYIt8t/ 8 | 9 | ## Agenda Items 10 | 11 | - Review action items from last meeting 12 | - Individual Status Updates 13 | - Review [Project Board](https://github.com/rust-lang/project-error-handling/projects/1) Issues 14 | - (low priority) https://github.com/rust-lang/rust/issues/80846 15 | - (out of scope) https://internals.rust-lang.org/t/syntax-for-returning-early-with-an-error/14181 16 | - (out of scope, superceded by try trait v2) https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/specialization.3A.20exclude.20traits.20or.20types/near/229141547 17 | - https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/static_assert.20for.20const.20generics/near/229109938 18 | 19 | # Attendees 20 | 21 | - Jane Lusby 22 | - Sean Chen 23 | - Charles Ellis O'Riley Jr. 24 | 25 | # Meeting Minutes 26 | 27 | ## Action Item Review 28 | - Jane still making last few changes to the blog post; it's almost done and ready for review and publishing. 29 | - Jane created tracking issues for low-priority tasks that have been sitting around for a while. 30 | - Charles has been working on the book diagram, which is coming along nicely. 31 | - Sean has no progress to report on book examples since the last meeting. 32 | - Jakub and Jane figured out the `rust-sv` crate error. 33 | - Jakub work's work on the termination trait stabilization is going well. 34 | - Jane created a zulip topic to discuss 3rd party libraries that ought to go in the book with the libs/lang teams. 35 | - Oliver has been triaging potential issues that have been coming in. 36 | 37 | ## Triaging Issues 38 | - (low priority) https://github.com/rust-lang/rust/issues/80846 39 | - Issue on differences between `std::panic!` and `core::panic!` behavior. 40 | - This is an edge case that most people won't encounter as it's being addressed by the 2021 edition. 41 | - Would be more worthwhile to spend time on getting `dyn Error` integrated with panics. 42 | - (out of scope) https://internals.rust-lang.org/t/syntax-for-returning-early-with-an-error/14181 43 | - Forum thread on `try` syntax, which is a lang team concern; this is explicitly out-of-scope for this working group. 44 | - (out of scope, superceded by try trait v2) https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/specialization.3A.20exclude.20traits.20or.20types/near/229141547 45 | - Thread about negative trait bounds, which probably won't play well with the trait solving engine, as it would make trait resolution an undecidable problem; the lang team is working on specialization instead. 46 | - Overlap of `From` impls for catch-all error types is already potentially handled by the new `Try` trait RFC, which makes it possible to handle the `From` impl as part of the `Try` type that wraps the catch-all error. 47 | - https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/static_assert.20for.20const.20generics/near/229109938 48 | - This is a diagnostic issue with the compiler; left up to the compiler team as to whether they'd like the error handling group to help out with this. 49 | -------------------------------------------------------------------------------- /meetings/2021-02-15.md: -------------------------------------------------------------------------------- 1 | # PEH 2021-02-15 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - Previous Meeting: https://github.com/rust-lang/project-error-handling/blob/master/meetings/2021-02-01.md 6 | - Action Items: https://hackmd.io/@rust-libs/Hyj7kRSld 7 | 8 | ## Agenda Items 9 | 10 | - Review action items from last meeting 11 | - Individual Status Updates 12 | - Any interest in scheduling regular 1 x 1s? 13 | - Review [Project Board](https://github.com/rust-lang/project-error-handling/projects/1) Issues 14 | 15 | # Attendees 16 | 17 | - Jane Lusby 18 | - Sean Chen 19 | - Charles Ellis O'Riley Jr. 20 | - Jakub Duchniewicz 21 | - DPC 22 | - oliver 23 | - Mara 24 | 25 | # Meeting Minutes 26 | 27 | - Reviewing open action items: 28 | - "Follow up on the 'Fix the Error trait' issue" is still unassigned: https://github.com/rust-lang/rust/issues/53487 29 | - Main thing that needs to happen is to remove the out of date items about the formatting repr for Backtrace. 30 | - Assigned to DPC 31 | - Regular meeting time was setup to work on the _Rust Error Book_. 32 | - Followed up with Charles explaining `Sized` and `assert2` 33 | - "Plan out changes needed to get `panic_error` added to std/core" assigned to Jane. 34 | 35 | - Action Items from the Previous Week 36 | - [x] Hack session to work on the _Rust Error Book_. 37 | - [ ] Follow up on `rust-sv` regression that was introduced with the `impl Error for &E: Error` change. 38 | - [ ] Follow up with infra team to get readership statistics on how many people read the blog post: https://blog.rust-lang.org/inside-rust/2020/11/23/What-the-error-handling-project-group-is-working-on.html. 39 | - Jane made progress on the "Backtrace in core" impl and is hoping to test it and start mass producing ICEs. 40 | - oliver and Jane made good progress on "Dig deeper into the Backtrace in core PR": https://github.com/rust-lang/rust/pull/77384 41 | - Jakub dug through and did some thinking on the "Termination trait polishing" issue: https://github.com/rust-lang/rust/issues/43301#issuecomment-761900006 42 | - May need to wait until the `Try` trait v2 RFC is further along since it may impact the design or impl of the Termination trait. 43 | - Once generic member access is added, we can have the Termination impl alway check the `&dyn Error` type for an `ExitCode` to be used as the exit code when terminating. 44 | - Ideally we'll want to see if we can minimize the dependency between Termination and the `ExitCode` so that Termination "just works" regardless of what extra functionality gets added to `ExitCode` down the line. 45 | 46 | - New Action Items Added 47 | - Schedule recurring meeting for book impl / study session [Jane] 48 | - Update API guidelines to add a section on implementing Display vs source: [unassigned] 49 | - Create an issue detailing plan for specializing unwrap / expect for E: Error [Jane] 50 | - Create an issue tracking the desire for an aborting interface for panics [unassigned] 51 | - Create an issue for a non allocating interface for printing a Backtrace [unassigned] 52 | - Create a diagram mapping out the pieces of error handling and how they relate for the book (e.g. Result, panic, Try, Error, etc) [unassigned] 53 | 54 | - Recurring _Rust Error Book_ session tentatively scheduled for 11 PST on Thursdays. 55 | - Add https://github.com/rust-lang/rust/pull/80851 and https://github.com/rust-lang/rfcs/pull/3058 to the list of PRs the group is watching. -------------------------------------------------------------------------------- /meetings/2020-09-28.md: -------------------------------------------------------------------------------- 1 | # Error Handling Project Group Agenda - 2020-09-28 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | ## Agenda Items 6 | 7 | - Prototyping an implementation of `std::core::Error` and stabilizing 8 | `#[feature(backtrace)]` 9 | - Identifying existing issues and RFCs that we should track 10 | - https://github.com/rust-lang/rfcs/pull/2895 11 | - Planning for "Communicating best practices" 12 | - "How users expect error handling to be, As in, we take a leap into the future 13 | and assume all this was implemented into the language, then how it would 14 | potentially look" 15 | 16 | 17 | # Meeting Minutes 18 | 19 | ## Participants 20 | 21 | People in attendance: 22 | - Jane Lusby 23 | - Sean Chen 24 | - Ashley Mannix 25 | - DPC 26 | - Mukund Lakshman 27 | - Jakub Duchniewicz 28 | - must-compute 29 | - Lance Zhang 30 | - Oliver 31 | - Charles Ellis O'Riley Jr. 32 | - Kyle Strand 33 | - Lokathor 34 | - Jubilee Young 35 | 36 | ## Topic 1: Discussing stabilizing `Backtrace` 37 | - Global hooks vs Boxing vs a trait-based approach for stabilizing `Backtrace` 38 | in `core`. 39 | - Going with the trait-based impl for `Backtrace` in core. 40 | - Private trait + public newtype wrapper. 41 | - Start with `eddyb`'s impl and see how many hooks are necessary along the 42 | way. 43 | - private trait with a public newtype wrapper 44 | - newtype wrapper is an interface not subject to coherence so we can add new 45 | methods without worrying about breaking changes downstream 46 | - https://doc.rust-lang.org/stable/src/std/io/error.rs.html#67-71 47 | - trait-based approaches have fewer magic compiler pieces and so would be easier 48 | to put together 49 | - `write_backtrace_to(&mut dyn FormatterThing) -> 50 | Result<(),FormatterThing::Error>` 51 | - ultimately about moving `Error` to core 52 | - should we do a trait object based solution internally with an unstable 53 | `Backtrace` trait in core and a stable `Backtrace` type in core or should it 54 | use global hooks like `panic_impl` 55 | - **need a prototype solution for exposing `Backtrace` as a type in `core` with 56 | the interface it currently provides in `std`** 57 | 58 | ## Topic 2: What RFCs should this group be tracking? 59 | - This group will have its own Project board to track relevant issues/RFCs. 60 | - Prep status reports on relevant issues we're tracking for future meetings. 61 | - Pulled from the [tracking board](https://github.com/rust-lang/libs-team/projects/2#column-10224181) 62 | - [#58520 tracking issue for error source iterators](https://github.com/rust-lang/rust/issues/58520) 63 | - [#53487 tracking issue for RFC 2504, "fix the error trait"](https://github.com/rust-lang/rust/issues/53487) 64 | - [#44838 tracking issue for RFC 2011: nicer assert messages](https://github.com/rust-lang/rust/issues/44838) 65 | - [#2895 RFC: generic member access for dyn error trait objects](https://github.com/rust-lang/rfcs/pull/2895) 66 | - [#58520 tracking issue for error source iterators](https://github.com/rust-lang/rust/issues/58520) 67 | 68 | ## Topic 3: Planning for "Communicating Best Practices" 69 | - Facilitate communication of best practices via a Book/documentation. 70 | - Should include some guidance on FFI error handling. 71 | - Adding a book section to the project repo (using mdbook). 72 | - Publish *The Rust Error Book* (name subject to change) and potentially 73 | contribute to *The Book* to make its error handling recommendations consistent 74 | with what this group decides. 75 | 76 | ## Topic 4: What is the long-term vision of what error handling in Rust looks like? 77 | - `Error` in `core`. 78 | - Stabilization of unstable `Error` interfaces. 79 | - Iterator API on `Backtrace`. 80 | - Generic member access (possibly with two-way flow). 81 | - Error return traces. 82 | - Some way to universally hook into all error reporting points for consistent 83 | error reporting. 84 | - Better handling of error enums 85 | - Guidance on FFI error handling. 86 | - Ways of recovering from recoverable errors. 87 | - enum-convergance as errors propagate up the stack 88 | -------------------------------------------------------------------------------- /meetings/2020-12-07.md: -------------------------------------------------------------------------------- 1 | # PEH 2020-12-07 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - [2020-11-23 Meeting Minutes](https://github.com/rust-lang/project-error-handling/blob/master/meetings/2020-11-23.md) 6 | 7 | ## Action Items 8 | 9 | - [[rust-lang/rust#77384]](https://github.com/rust-lang/rust/pull/77384) Implement trait based proof of concept for `Backtrace` in `core` (Jane Lusby) 10 | - [[rust-lang/rfcs#2895]](https://github.com/rust-lang/rfcs/pull/2895) Update `object-provider` API in generic member access RFC (Jane Lusby) 11 | - [[rust-lang/rust#75180]](https://github.com/rust-lang/rust/pull/75180) Fix regressions caused by new impl error for `&'a E` change (Jakub Duchniewicz) 12 | - [[rust-lang/rust#53487]](https://github.com/rust-lang/rust/issues/53487) Review the "Fix the error trait" tracking issue to figure out next steps (Oliver) 13 | - [[rust-lang/rfcs#3007]](https://github.com/rust-lang/rfcs/pull/3007) Review the panic plan rfc (Jane Lusby) 14 | - [[rust-lang/project-error-handling#7]](https://github.com/rust-lang/project-error-handling/issues/7) reach out to the author of the error codes issue (Jane Lusby) 15 | - Get long-term blog post posted on Inside Rust blog (Sean Chen) 16 | - [[rust-lang/rust#72981]](https://github.com/rust-lang/rust/pull/72981) 17 | - Resolve blockers in the backtrace stabilizition PR (Ashley Mannix) 18 | - Follow up with Amanieu to mark concerns on backtrace stabilization as resolved (Ashley Mannix) 19 | - [[rust-lang/project-error-handling#24]](https://github.com/rust-lang/project-error-handling/issues/24) Create an issue and gather resources to use as reference material for the Rust Error Book (Jane Lusby) 20 | 21 | ## Agenda Items 22 | 23 | - Review action items from last meeting 24 | - Merge conflicts on backtrace stabilization PR 25 | - Review to merge project board updates 26 | - disposition: add to project board 27 | - https://github.com/rust-lang/rust/issues/54144 28 | - https://github.com/rust-lang/rust/issues/54889 29 | - https://github.com/rust-lang/rust/issues/40322 30 | - backtrace frames PR 31 | - backtrace format PR 32 | - disposition: out of scope 33 | - https://github.com/rust-lang/rust/issues/34472 34 | - https://github.com/rust-lang/rust/issues/36749 35 | - https://github.com/rust-lang/rust/issues/37179 36 | - https://github.com/rust-lang/rust/issues/43354 37 | - https://github.com/rust-lang/rust/issues/37634 38 | - https://github.com/rust-lang/rust/issues/37871 39 | - https://github.com/rust-lang/rust/issues/41407 40 | - https://github.com/rust-lang/rust/issues/42154 41 | - https://github.com/rust-lang/rust/issues/51588 42 | - https://github.com/rust-lang/rust/issues/30974 43 | - https://github.com/rust-lang/rust/issues/49129 44 | - https://github.com/rust-lang/rust/issues/51125 45 | - Holiday Schedule 46 | 47 | # Attendees 48 | 49 | - oliver :cake: 50 | - Jane Lusby 51 | - Charles Ellis O'Riley Jr. 52 | - Jakub Duchniewicz 53 | - DPC 54 | 55 | # Meeting Minutes 56 | - Rust Error Book 57 | - [references collection](https://github.com/rust-lang/project-error-handling/issues/24) 58 | - Backtrace Stabilization 59 | - disposition merge 60 | - [merge conflicts](https://github.com/rust-lang/rust/pull/79692) 61 | - Error Codes Issues 62 | - low priority 63 | - Fix Error Trait 64 | - ready for finalization, seeking the right person for completion 65 | - [#75180](https://github.com/rust-lang/rust/pull/75180) 66 | - PR coming shortly 67 | - [#2895 RFC generic member access for dyn Error trait objects](https://github.com/yaahc/rfcs/blob/master/text/0000-dyn-error-generic-member-access.md) 68 | - possibility of updating the object-provider API to possibly allow 69 | extracting context which includes lifetimes 70 | - on implemented version uses marker types which implement a trait with 71 | an associated type to provide a static type to downcast to as a proxy for 72 | a type which cannot have a type id because it contains lifetimes 73 | - https://github.com/mystor/dyno 74 | -------------------------------------------------------------------------------- /error-design-patterns-book/collect-references-here: -------------------------------------------------------------------------------- 1 | ### References Are Collected Here 2 | 3 | #### Intro Summary 4 | #### Generalities of Error Handling 5 | #### Rust's Idioms for Handling Errors 6 | 7 | #### Advanced Error Design Patterns 8 | https://rust-lang-nursery.github.io/failure/guidance.html 9 | 10 | #### Error Anti-Patterns 11 | #### FFI 12 | #### Glossary 13 | #### Appendices/Additional Resources 14 | 15 | #### Uncategorized 16 | http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2429.pdf 17 | https://250bpm.com/blog:12/ 18 | https://archive.fosdem.org/2020/schedule/event/the_history_of_error_correction_and_detection_and_how_it_led_to_ceph_s_erasure_coding_techniques/ 19 | https://arzg.github.io/lang/18/ 20 | https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html 21 | https://blog.rust-lang.org/2020/12/11/lock-poisoning-survey.html 22 | https://blog.rust-lang.org/inside-rust/2020/11/23/What-the-error-handling-project-group-is-working-on.html 23 | https://blog.rust-lang.org/inside-rust/2020/11/23/What-the-error-handling-project-group-is-working-on.html#one-standardized-error-trait 24 | https://blog.yoshuawuyts.com/error-handling-survey/ 25 | https://boats.gitlab.io/blog/post/the-problem-of-effects/ 26 | https://boats.gitlab.io/failure/ 27 | https://bryce.fisher-fleig.org/strategies-for-returning-references-in-rust/ 28 | https://crates.io/crates/anyhow 29 | https://crates.io/crates/extracterr 30 | https://crates.io/crates/eyre 31 | https://crates.io/crates/failure 32 | https://crates.io/crates/thiserror 33 | https://deterministic.space/hook-into-rustc-errors.html 34 | https://dev.to/cad97/try-fn-without-special-casing-result-4m5b 35 | https://dev.to/e_net4/migrating-from-quick-error-to-snafu-a-story-on-revamped-error-handling-in-rust-58h9 36 | https://diziet.dreamwidth.org/9894.html 37 | https://doc.rust-lang.org/error-index.html 38 | https://docs.rs/adhocerr/0.1.2/adhocerr/ 39 | https://docs.rs/color-eyre/0.5.4/color_eyre/section/trait.Section.html 40 | https://docs.rs/color-eyre/0.5.4/src/color_eyre/lib.rs.html#397-408 41 | https://docs.rs/error/0.1.9/error/macro.match_error.html 42 | https://docs.rs/error/0.1.9/src/error/lib.rs.html#99-115 43 | https://docs.rs/http-types/2.4.0/http_types/struct.Error.html 44 | https://domwillia.ms/panik/ 45 | https://dr-knz.net/go-errors-vs-exceptions-2020.html 46 | https://edgarluque.com/blog/wrapping-errors-in-rust 47 | https://fuchsia.dev/fuchsia-src/concepts/kernel/exceptions 48 | https://gcc.gnu.org/legacy-ml/gcc-help/2009-10/msg00195.html 49 | https://gendignoux.com/blog/2021/04/01/rust-async-streams-futures-part1.html 50 | https://github.com/Peternator7/strum/wiki/Derive-EnumProperty 51 | https://github.com/apple/swift-evolution/blob/master/proposals/0276-multi-pattern-catch-clauses.md 52 | https://github.com/fusion-engineering-forks/rfcs/blob/panic/text/0000-panic-plan.md 53 | https://github.com/must-compute/the-rust-error-book 54 | https://github.com/rust-lang/project-error-handling/blob/master/CHARTER.md 55 | https://github.com/rust-lang/project-error-handling/issues/3 56 | https://github.com/rust-lang/project-error-handling/issues/7 57 | https://github.com/rust-lang/rfcs/blob/master/text/2965-project-error-handling.md 58 | https://github.com/rust-lang/rust/issues/66731 59 | https://github.com/rust-lang/rust/pull/72981#issuecomment-707405697 60 | https://github.com/rust-lang/rust/pull/75180 61 | https://github.com/seanchen1991/blog/blob/main/posts/extending-minigrep/index.md 62 | https://github.com/yaahc/rfcs/blob/master/text/0000-dyn-error-generic-member-access.md 63 | https://hackmd.io/@kQlAmwdASwqEXB8JsIkvyw/H1V0MKFvw 64 | https://haskellweekly.news/episode/35.html 65 | https://huonw.github.io/blog/2014/06/error-handling-in-rust-knn-case-study/ 66 | https://internals.rust-lang.org/t/ideas-around-anonymous-enum-types/12627 67 | https://internals.rust-lang.org/t/lifetime-parameter-default-value/1722 68 | https://matklad.github.io/2020/10/15/study-of-std-io-error.html 69 | https://mbuffett.com/posts/rust-less-error-handling/ 70 | https://meltware.com/2020/10/21/rust-async-nonsense.html 71 | https://ncbi.github.io/cxx-toolkit/pages/ch_debug 72 | https://nick.groenen.me/posts/rust-error-handling/ 73 | https://paper.dropbox.com/doc/Collaborative-Summary-3-Fact-Finding-Pre-RFCs-around-Error-Handling-Reporting-dnShKo1SsHtdF4Yheeoco 74 | https://pingcap.com/blog/rust-huge-compilation-units 75 | https://rpeszek.github.io/posts/2021-01-17-maybe-overuse.html 76 | https://rustc-dev-guide.rust-lang.org/panic-implementation.html?highlight=panic_handler#panicking-in-rust 77 | https://saidvandeklundert.net/learn/2021-09-01-rust-option-and-result/ 78 | https://sled.rs/errors 79 | https://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/ 80 | https://smallcultfollowing.com/babysteps/blog/2018/04/24/rust-pattern-precise-closure-capture-clauses/ 81 | https://tarquin-the-brave.github.io/blog/posts/collecting-all-the-errors/ 82 | https://taylor.fausak.me/2021/04/03/default-exception-handler-in-haskell/ 83 | https://users.rust-lang.org/t/an-essay-of-checked-exceptions-in-rust/57769 84 | https://vorner.github.io/2020/04/13/hyper-traps.html 85 | https://vorner.github.io/2021/01/03/dark-side-of-posix-apis.html 86 | https://www.boost.org/community/exception_safety.html 87 | https://www.eyalkalderon.com/nom-error-recovery/ 88 | https://www.fpcomplete.com/blog/async-exceptions-haskell-rust/ 89 | https://www.fpcomplete.com/blog/error-handling-is-hard/ 90 | https://www.hackingwithswift.com/new-syntax-swift-2-error-handling-try-catch 91 | https://www.halcyon.hr/posts/error-handling-in-rust/ 92 | https://www.haskellforall.com/2021/01/dynamic-type-errors-lack-relevance.html 93 | https://www.modernescpp.com/index.php/c-core-guidelines-rules-to-error-handling 94 | https://www.ralfj.de/blog/2019/11/25/how-to-panic-in-rust.html 95 | https://yaah.dev/building-your-own-error-type 96 | https://yaah.dev/try-blocks 97 | -------------------------------------------------------------------------------- /meetings/2020-10-12.md: -------------------------------------------------------------------------------- 1 | # PEH Meeting Agenda - 2020-10-12 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - [2020-09-28 Meeting Minutes](https://github.com/rust-lang/project-error-handling/blob/master/meetings/2020-09-28.md) 6 | 7 | ## Action Items 8 | 9 | - Implement trait based proof of concept for `Backtrace` in `core` (Jane Lusby) 10 | - Setup `The Rust Error Book` (must-compute, Charles Ellis O'Riley Jr, and Jakub Duchniewicz) 11 | - Draft a [blog post](https://hackmd.io/GMLcORX_R7W4de0ZryDIxg?view) detailing the long-term vision of what this group thinks Rust error handling should look like (Sean Chen) 12 | - Status Updates on Tracked issues (What's the current status, what are the next steps, what are the blockers, is it actively being worked on) 13 | - [Generic Member Access](https://github.com/rust-lang/rfcs/pull/2895) (Jane Lusby) 14 | - [Fix the error trait / Stabilizing Backtrace](https://github.com/rust-lang/rust/issues/53487) (Jane Lusby) 15 | - [stabilizing error source iterators](https://github.com/rust-lang/rust/issues/58520) (Oliver) 16 | - [Box error alias](https://github.com/rust-lang/rfcs/pull/2820) (unassigned) 17 | - [stabilizing Error::type_id](https://github.com/rust-lang/rust/issues/60784) (Jakub Duchniewicz) 18 | - [PanicInfo::message](https://github.com/rust-lang/rust/issues/66745) (DPC) 19 | - [nicer assert messages](https://github.com/rust-lang/rust/issues/44838) (Charles Ellis O'Riley Jr.) 20 | - Moving forward with adding an iterator API to `backtrace` (Sean Chen) 21 | 22 | ## Agenda Items 23 | 24 | - Review action items from last meeting 25 | - Review open issues on project group repository 26 | - Anything to buble up to the Libs meeting? 27 | 28 | # Meeting Minutes 29 | 30 | ## Participants 31 | 32 | People in attendance: 33 | - Jane Lusby 34 | - Sean Chen 35 | - Ashley Mannix 36 | - Kyle Strand 37 | - Lance Zhang 38 | - Jeremiah Senkpiel 39 | - Jakub Duchniewicz 40 | - DPC 41 | - oliver 42 | - Charles Ellis O'Riley Jr. 43 | - must-compute 44 | - Jubilee Young 45 | 46 | ## Backtrace in core 47 | 48 | - So far the implementation is moving forward fine, but there are questions around the hooks 49 | - Not clear how to set them up with a default in `no_std` so users don't _need_ to write one like `#[panic_handler]` 50 | - Current work in progress [here](https://github.com/rust-lang/rust/pull/77384) 51 | - There's enough sketched out that it shouldn't be a blocker for stabilizing `backtrace` anymore 52 | 53 | ## The Rust Error Book 54 | 55 | - We now have a folder in the `project-error-handling` repository for content 56 | 57 | ## Log-term project group vision and goals 58 | 59 | - Draft here: https://hackmd.io/GMLcORX_R7W4de0ZryDIxg?view 60 | 61 | ## Generic member access RFC 62 | 63 | - There's an updated API in `object-provider` that the RFC would like to use 64 | - Once the content is updated it needs some Libs input 65 | - There could be some tie in with `tide`'s `Response` type? 66 | 67 | ## Fix the `Error` trait / Stabilizing `backtrace` 68 | 69 | - Covered in the earlier discussion on _Backtrace in core_ 70 | - There could be some documentation work to do on `backtrace` 71 | 72 | ## Stabilizing `Error` source iterators 73 | 74 | - stabilizing error source iterators 75 | - trait objects vs. provided methods 76 | - [stabilization report 2020-09-14](https://github.com/rust-lang/rust/issues/58520#issuecomment-691982191) 77 | - unergonomic use-cases ---> difficulties stabilizing 78 | - bugs 79 | - blocked on [#53487](https://github.com/rust-lang/rust/issues/53487) 80 | - [#75180](https://github.com/rust-lang/rust/pull/75180) might feed into this too 81 | - related crate [`error-chain`](https://crates.io/crates/error-chain) 82 | 83 | ## Stabilizing `Error::type_id` 84 | 85 | - Several possible approaches, but all are waiting for other stabilizations/RFCs 86 | - #[marker] trait stabilization: https://github.com/rust-lang/rust/issues/29864 87 | - negative trait impls 88 | - dynamic vtable type_id (like C++ typeid keyword) https://github.com/rust-lang/rfcs/pull/2580 89 | - final keyword -> no overriding of trait any more 90 | - new trait TypeInfo https://github.com/rust-lang/rfcs/pull/2738 91 | - Not clear it's something we want to stabilize 92 | - Looks like a rabbit hole we don't want to go down right now 93 | 94 | ## `PanicInfo::message` 95 | 96 | - No progress made here 97 | 98 | ## Nicer Assert Messages 99 | 100 | - [RFC](https://github.com/rust-lang/rfcs/pull/2011) has been approved, with no implementation started yet 101 | - Does this need to be implemented using the compiler's built-in proc macros, or can it be done as an external crate using `pro-macros` and `syn`? 102 | - Need external thoughts/mentorship on this question 103 | 104 | ## Iterating over `Backtrace` frames 105 | 106 | - Just starting out, so there hasn't been much discussion yet 107 | - The `backtrace` crate has a `frames()` fn that already exposes its individual frames 108 | - We could propose basically the same thing for `std`'s `Backtrace` type 109 | 110 | # Outcomes 111 | 112 | ## Backtrace in core 113 | 114 | - @KodrAus to ping https://github.com/rust-lang/rust/pull/72981 and raise at Libs meeting RE `backtrace` stabilization 115 | 116 | ## Long-term project group vision and goals blog post 117 | 118 | - @Jane Lusby @Jakub Duchniewicz @KodrAus to review draft content 119 | 120 | ## Generic member access RFC 121 | 122 | - @Jane Lusby to incorporate changes from `object-provider` 123 | - @KodrAus to review RFC and ping Libs 124 | 125 | ## Stabilizing `Error` source iterators 126 | 127 | - Looks like many parts of this are stuck on fixing the `Error` trait, so our efforts should be focused here to push this forward 128 | 129 | ## Stabilizing `Error::type_id` 130 | 131 | - Putting this one on the back burner 132 | 133 | ## Nicer Assert Messages 134 | 135 | - Look into whether we can implement an external POC for this ourselves 136 | - Need external advice/mentorship (possibly from t-libs-impl) before we can get started on it 137 | 138 | ## Iterator API on Backtrace 139 | 140 | - @Sean Chen to look more into this initiative 141 | - Export an identical `fn frames(&self) -> &[BacktraceFrame]` to `std` 142 | - Add it as an unstable API to `Backtrace` without an RFC to start with (just an FCP on the implementation itself) 143 | -------------------------------------------------------------------------------- /meetings/2020-10-26.md: -------------------------------------------------------------------------------- 1 | # PEH 2020-10-26 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - [2020-10-12 Meeting Minutes](https://github.com/rust-lang/project-error-handling/blob/master/meetings/2020-10-12.md) 6 | 7 | ## Attendees 8 | 9 | - Jane Lusby 10 | - Ashley Mannix 11 | - Oliver :) 12 | - Jeremiah Senkpiel 13 | - Charles Ellis O'Riley Jr. 14 | - Sean Chen 15 | - Mara 16 | - DPC 17 | 18 | ## Action Items 19 | 20 | - Implement trait based proof of concept for `Backtrace` in `core` (Jane Lusby) 21 | - Update `object-provider` API in generic member access RFC (Jane Lusby) 22 | - Create a tracking issue to document why `Box` and related types do not implement the Error trait, what prevents it, and what would be needed moving forward (Ashley Mannix) [zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/257204-project-error-handling/topic/impl.20Error.20or.20dyn.20Error.3F/near/213235983) 23 | - Fill out table of contents of expected sections in `The Rust Error Book` (Oliver) 24 | - Review long-term vision blog post (Jane Lusby, Jakub Duchniewicz, Ashley Mannix) 25 | - Begin process of stabilization of `Backtrace` and `fn backtrace` (Ashley Mannix) 26 | - Resolve last blockers in `Fix The Error Trait` tracking issue (Oliver) 27 | - Status update on [PanicInfo::message](https://github.com/rust-lang/rust/issues/66745) (DPC) 28 | - Get mentorship instructions for implementing [`Nicer Assert Messages`](https://github.com/rust-lang/rust/issues/44838) RFC and begin implementation (Charles Ellis O'Riley Jr. and DPC) 29 | - Add unstable `fn frames(&self) -> &[BacktraceFrame]` method to `Backtrace` on nightly based on `backtrace` crate's API (Sean Chen and Ashley Mannix) 30 | 31 | ## Agenda Items 32 | 33 | - Review action items from last meeting 34 | - Begin tracking https://github.com/fusion-engineering-forks/rfcs/blob/panic/text/0000-panic-plan.md, status update from [@m-ou-se](https://github.com/m-ou-se) 35 | - Review open issues on project group repository 36 | - Anything to bubble up to the Libs meeting? 37 | 38 | ## Summary 39 | 40 | ### `impl<'a, E: Error + Sized + 'a> Error for &'a E` 41 | 42 | - We believe we should pursue stabilizing this. There's already an open PR to update: https://github.com/rust-lang/rust/pull/75180 43 | 44 | ### `dyn Error` or `impl Error`? 45 | 46 | - We think the recommendation of `&(dyn Error + 'static)` for borrowed abstract errors and `impl Error + Send + Sync + 'static` for owned abstract errors is reasonable. 47 | 48 | ### Table of contents for the Rust book 49 | 50 | - We've sketched out a table of contents that's ready to PR back to the main repository. 51 | 52 | ### Stabilization for `Backtrace` 53 | 54 | - There's a current question about whether it's a problem that `Backtrace` doesn't share much with the internal machinery used to print panic backtraces. 55 | - @KodrAus is looking into it, and will post an update on the stabilization PR. 56 | - The panic implementation is a little different because it doesn't require all frames to be captured upfront, which is important for panic-on-oom support. Even if we don't share everything we should be able to share a little more between `sys_common::backtrace` and `backtrace`. 57 | 58 | ### Fixing the `Error` 59 | 60 | - The last outstanding item is that you can't use the precision flag to limit the number of frames being printed when formatting a backtrace. This doesn't need to block stabilization, and `Backtrace::frames` should also make it less important. 61 | 62 | ### `PanicInfo::message` 63 | 64 | - It's currently in progress. 65 | 66 | ### Better assert RFC 67 | 68 | - It's currently in progress. 69 | 70 | ### `Backtrace::frames` 71 | 72 | - There's an open PR for it that we're working through. 73 | 74 | ### Vision blog post 75 | 76 | - It's been updated with the latest round of feedback and is ready to go! 77 | 78 | # Meeting Minutes 79 | 80 | Meeting called to order at 13:00 81 | Review of Action Items 82 | Review of implementing the backtrace in core PoC and updating the object provider RFC. No updates from Jane Lusby on those two items. Jane made a separate trackingh issue for box dyn error. 83 | 84 | Ashley Mannix will write a stabilization report for &dyn Error. 85 | 86 | action item: adding a table of contents for the rust book to which oliver will add a PR to project-error-handling repo for adding a table of contents for the rust book. 87 | 88 | @Ashley Mannix will investigate @ralfjung concerns abount pacin! relying on different internals than backtrace itself does 89 | 90 | next action item: resolving the "Fix The Error Trait" issue by @oliver which he's still looking into. Subsequent conversation on this issue determined that "fix backtrace's fmt" has been done and that the fancy extra fmt features could be spli into seperate tracking issues. 91 | 92 | next action item: @DPC status update on the "PanicInfo::message" PR which he started started working on it. 93 | 94 | next action item: Charles Ellis O'Riley Jr. and @DPC have been working on implementing the Better assert RFC. @Charles Ellis O'Riley Jr forked and cloned the repo Copied and filled in the config.toml file and ran the x.py command which produced more errors that I need to work through. 95 | 96 | next action item: backtrace frame. @Sean Chen started a draft PR for it. 97 | 98 | agenda item: @Mara has opened a new RFC for fixing inconsistencies between core and std panic. In summary the proposal is to make std's and core's panic macro the same one, and make it behave identically to print!() in how it uses its arguments so panic!("{}") and panic!(123) etc. will no longer compile. 99 | 100 | next agenda item: there are 7 open issues on the project group repo of which 3 have been discussed in this meeting, the impl Error for E: Error one and the backtrace proof of concept, and backtrace frames API 101 | 102 | @Jakub Duchniewicz will check into this globally consistent error reporting 103 | 104 | @Jane Lusby will look into Posix errors (the author) 105 | 106 | * move std::io::Error to core is currently blocked 107 | * error return traces are blocked by the generic member access RFC 108 | 109 | End of meeting. 110 | 111 | 112 | ## Participants 113 | 114 | People in attendance: 115 | Jane Lusby 116 | Ashley Mannix 117 | Oliver :cat2: 118 | Jeremiah Senkpiel 119 | DPC 120 | Mara 121 | Jakub Duchniewicz 122 | Sean Chen 123 | Charles Ellis O'Riley Jr. 124 | -------------------------------------------------------------------------------- /draft-rfcs/error-reporter-rfc-template.md: -------------------------------------------------------------------------------- 1 | - Feature Name: error reporter 2 | - Start Date: 2021-05-17 3 | - RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000) 4 | - Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000) 5 | 6 | # Summary 7 | [summary]: #summary 8 | 9 | Specialization already works for concrete types, so we could 10 | specialize the `Termination` impl specifically for `Box` 11 | today, there's nothing blocking this. That way we can confidently 12 | point people towards `fn main() -> Result<(), Box>` knowing 13 | that it will output the right thing. :tada: 14 | 15 | # Motivation 16 | [motivation]: #motivation 17 | 18 | Currently all errors reported via the `Termination` impl on 19 | `core::result::Result` go through `Debug` instead of `Error`, which 20 | tends to be the wrong choice for errors. We have plans for fixing this 21 | via specialization but these plans are blocked on workarounds for a 22 | soundness issue and wouldn't even apply to `Box` which 23 | _doesn't even implement the `Error` trait_. We cannot fix this as far 24 | as we can tell, but it turns out we probably don't need to for this 25 | specific case! 26 | 27 | # Guide-level explanation 28 | [guide-level-explanation]: #guide-level-explanation 29 | 30 | Explain the proposal as if it was already included in the language and 31 | you were teaching it to another Rust programmer. That generally means: 32 | 33 | - Introducing new named concepts. 34 | - Explaining the feature largely in terms of examples. 35 | - Explaining how Rust programmers should *think* about the feature, 36 | and how it should impact the way they use Rust. It should explain 37 | the impact as concretely as possible. 38 | - If applicable, provide sample error messages, deprecation warnings, 39 | or migration guidance. 40 | - If applicable, describe the differences between teaching this to 41 | existing Rust programmers and new Rust programmers. 42 | 43 | For implementation-oriented RFCs (e.g. for compiler internals), this 44 | section should focus on how compiler contributors should think about 45 | the change, and give examples of its concrete impact. For policy RFCs, 46 | this section should provide an example-driven introduction to the 47 | policy, and explain its impact in concrete terms. 48 | 49 | # Reference-level explanation 50 | [reference-level-explanation]: #reference-level-explanation 51 | 52 | This is the technical portion of the RFC. Explain the design in 53 | sufficient detail that: 54 | 55 | - Its interaction with other features is clear. 56 | - It is reasonably clear how the feature would be implemented. 57 | - Corner cases are dissected by example. 58 | 59 | The section should return to the examples given in the previous 60 | section, and explain more fully how the detailed proposal makes those 61 | examples work. 62 | 63 | # Drawbacks 64 | [drawbacks]: #drawbacks 65 | 66 | - many similar types with auto traits 67 | [programmerjake](https://github.com/rust-lang/project-error-handling/issues/40#issuecomment-840789700): 68 | `Box, Box, ...` 69 | 70 | # Rationale and alternatives 71 | [rationale-and-alternatives]: #rationale-and-alternatives 72 | 73 | - Why is this design the best in the space of possible designs? 74 | - What other designs have been considered and what is the rationale 75 | for not choosing them? 76 | - What is the impact of not doing this? 77 | 78 | # Prior art 79 | [prior-art]: #prior-art 80 | 81 | Discuss prior art, both the good and the bad, in relation to this 82 | proposal. 83 | A few examples of what this can include are: 84 | 85 | - For language, library, cargo, tools, and compiler proposals: Does 86 | this feature exist in other programming languages and what 87 | experience have their community had? 88 | - For community proposals: Is this done by some other community and 89 | what were their experiences with it? 90 | - For other teams: What lessons can we learn from what other 91 | communities have done here? 92 | - Papers: Are there any published papers or great posts that discuss 93 | this? If you have some relevant papers to refer to, this can serve 94 | as a more detailed theoretical background. 95 | 96 | This section is intended to encourage you as an author to think about 97 | the lessons from other languages, provide readers of your RFC with a 98 | fuller picture. If there is no prior art, that is fine - your ideas 99 | are interesting to us whether they are brand new or if it is an 100 | adaptation from other languages. 101 | 102 | Note that while precedent set by other languages is some motivation, 103 | it does not on its own motivate an RFC. Please also take into 104 | consideration that rust sometimes intentionally diverges from common 105 | language features. 106 | 107 | # Unresolved questions 108 | [unresolved-questions]: #unresolved-questions 109 | 110 | - What parts of the design do you expect to resolve through the RFC 111 | process before this gets merged? 112 | - What parts of the design do you expect to resolve through the 113 | implementation of this feature before stabilization? 114 | - What related issues do you consider out of scope for this RFC that 115 | could be addressed in the future independently of the solution that 116 | comes out of this RFC? 117 | 118 | # Future possibilities 119 | [future-possibilities]: #future-possibilities 120 | 121 | Think about what the natural extension and evolution of your proposal 122 | would be and how it would affect the language and project as a whole 123 | in a holistic way. Try to use this section as a tool to more fully 124 | consider all possible interactions with the project and language in 125 | your proposal. Also consider how this all fits into the roadmap for 126 | the project and of the relevant sub-team. 127 | 128 | This is also a good place to "dump ideas", if they are out of scope 129 | for the RFC you are writing but otherwise related. 130 | 131 | If you have tried and cannot think of any future possibilities, you 132 | may simply state that you cannot think of anything. 133 | 134 | Note that having something written down in the future-possibilities 135 | section is not a reason to accept the current or a future RFC; such 136 | notes should be in the section on motivation or rationale in this or 137 | subsequent RFCs. The section merely provides additional information. 138 | -------------------------------------------------------------------------------- /meetings/2020-11-09.md: -------------------------------------------------------------------------------- 1 | # PEH 2020-11-09 Meeting Agenda 2 | 3 | ###### tags: `Error Handling` `Minutes` 4 | 5 | - [2020-10-26 Meeting Minutes](https://github.com/rust-lang/project-error-handling/blob/master/meetings/2020-10-26.md) 6 | 7 | ## Action Items 8 | 9 | - Implement trait based proof of concept for `Backtrace` in `core` (Jane Lusby) 10 | - Update `object-provider` API in generic member access RFC (Jane Lusby) 11 | - Move forward with adding an Error impl for `&impl Error` (Ashley Mannix) 12 | - Create an FCP on the existing PR 13 | - Add guidance for using &dyn Error + 'static and impl Error + Send + Sync + 14 | 'static for borrow and owned errors respectively 15 | - Review the "Fix the error trait" tracking issue to figure out next steps 16 | (Oliver + Ashley Mannix) 17 | - Review the panic plan rfc (Jane Lusby) 18 | - reach out to the author of the error codes issue (Jane Lusby) 19 | - Discuss universally consistent error reporting (Jane Lusby, Jakub Duchniewicz, 20 | and Jeremiah Senkpiel) 21 | - Post long term plan blog post (Sean Chean & Jane Lusby) 22 | - Begin writing chapters for The Rust Error Book (unassigned) 23 | - Resolve blockers in the backtrace stabilizition PR (Ashley Mannix) 24 | 25 | ## Agenda Items 26 | 27 | - Review action items from last meeting 28 | - Review tracked issues in our [Project Board](https://github.com/rust-lang/project-error-handling/projects/1) 29 | - [RFC#2580 related to 'Stabilizing `Error::type_id`'](https://hackmd.io/1Fq9TcAQRWa4_weWTe9adA) 30 | - Anything to bubble up to the Libs meeting? 31 | - Review `The Rust Error Book` looking to add initial content 32 | - 2021 Rust Edition 33 | - postponed? 34 | - Discuss meeting time 35 | 36 | # Meeting Minutes 37 | 38 | Called to order at 13:00 PST 39 | 40 | ## Attendees 41 | 42 | - Jane Lusby 43 | - Sean Chen 44 | - Oliver 45 | - Ashley Mannix 46 | - Mara 47 | - Jakub Duchniewicz 48 | - DPC 49 | 50 | ## Progress on Backtrace in Core [Jane Lusby] 51 | - No progress on this since last time 52 | 53 | ## Update Generic Member Access API [Jane Lusby] 54 | - Reviewed changes made by Nika 55 | - We should be using rustc errors as an example in the RFC 56 | - Universal reporting is still messy and depends on features that don't exist 57 | yet 58 | - RFC for this is basically complete with some pending updates including 59 | examples related to compiler error reporting 60 | 61 | ## Adding an Error impl for `&impl Error` [Ashley Mannix] 62 | - In final comment period. Will go in 1.49.0 when it's ready to go. 63 | - starting patching for related libraries 64 | 65 | ## Review the “Fix the error trait” tracking issue [Oliver + Ashley Mannix] 66 | - No progress on this 67 | 68 | ## Review the panic plan rfc [Jane Lusby] 69 | - Now waiting for the FCP checkboxes; four more to go 70 | 71 | ## Reach out to the author of the error codes issue [Jane Lusby] 72 | - Didn't get to this 73 | 74 | ## Post long term plan blog post [Sean Chean & Jane Lusby] 75 | - Haven't put in suggested changes yet. 76 | 77 | ## Begin writing chapters for The Rust Error Book [unassigned] 78 | - Put out a call for a collection of references 79 | - Are we targeting 2021 edition? 80 | - Not particularly; shouldn't have any major breaking changes 81 | - Besides unifying `panic`, shouldn't have anything that interacts with 82 | editions 83 | - Universal error reporting _might_ become something that involves requiring 84 | a breaking change, but too nebulous to know at the moment 85 | 86 | 87 | ## Resolve blockers in the backtrace stabilizition PR [Ashley Mannix] 88 | - Different implementions for panics and errors since the panic backtrace 89 | resolver can resolve frames in the presence of memory errors. 90 | - Code between the two implementations can be shared, though this probably 91 | doesn't have implications on the API. 92 | - Unlisted concern in FCP 93 | - Blocked on Amanieu having time to look through the recent discussion to 94 | mark concern as resolved 95 | 96 | ## Discuss universally consistent error reporting [Jane Lusby, Jakub Duchniewicz, and Jeremiah Senkpiel] 97 | - Trying to find a way to introduce a "Reporter" that handles displaying `E: 98 | Error` objects and additionally captures context relevant to those errors. 99 | - Maybe extend this type to also handle `PanicInfo` objects 100 | - Should naturally fit the design of the Error trait 101 | - `PanicInfo` already has this handled by the hook from `set_hook` 102 | - Unification will be a challenge 103 | 104 | ## Backtrace Frames Method [Sean Chen] 105 | - Started on this, though need to continue working through details from @KodrAus 106 | - Suggestion to use a wrapper to return a borrow to data behind a `Mutex` 107 | - @KodrAus -- for safety should materialize a `Vec` behind a wrapper 108 | - additional suggestions forthcoming 109 | 110 | ## Nicer Assert Messages [Charles Ellis O'Riley Jr.] 111 | - Charles not in attendance today; punt this to next meeting 112 | 113 | ## `PanicInfo::message` RFC [DPC] 114 | - `de-vri-es` doing some work related to this 115 | - Trying to add some kind of `AssertionInfo` to a `PanicInfo` that the test 116 | crate can use to displays things more nicely without requiring support for 117 | colors in std 118 | 119 | ## `Error::type_id` [unassigned] 120 | - Should enable a way to have function specialization such that `type_id` would 121 | be specialized for every type 122 | - Priority: low 123 | 124 | ## Changing the Meeting Time going forward 125 | - SIMD meeting starts right after this one 126 | - Ideally, shift meeting back an hour for Daylight Savings and call it a day 127 | - If not, might have to do another poll for meeting times 128 | - Brought up in last week's SIMD meeting; didn't seem like anybody have issues 129 | with shifting it 130 | 131 | # Todo 132 | ## Blog post coming soon 133 | - goals to be run by project group before starting something on internals 134 | 135 | ## Update Object Provider API [Jane Lusby] 136 | - Add Nika's changes to RFC @2aetCAHHS5yPrDQIgqGo2Q 137 | 138 | ## Adding an Error impl for `&impl Error` [Ashley Mannix] 139 | - We can start patching libraries that it will break to get it ready for 1.49.0 140 | @KodrAus 141 | 142 | ## Discuss universally consistent error reporting [Jane Lusby, Jakub Duchniewicz, and Jeremiah Senkpiel] 143 | - Draft a blog post laying this out @2aetCAHHS5yPrDQIgqGo2Q 144 | 145 | ## Review "The Rust Error Book" to add additional content 146 | - Create an issue and gather existing resources to use as references for the 147 | book @2aetCAHHS5yPrDQIgqGo2Q 148 | 149 | ## Resolve blockers in the backtrace stabilizition PR [Ashley Mannix] 150 | - Reach out to Amanieu to get their concerns resolved @KodrAus 151 | -------------------------------------------------------------------------------- /CHARTER.md: -------------------------------------------------------------------------------- 1 | # Charter 2 | [charter]: #charter 3 | 4 | ## Goals 5 | 6 | ### Agree on and define common error handling terminology 7 | 8 | - Recoverable error: An error that can be reacted and recovered from when 9 | encountered e.g. a missing file. 10 | - Unrecoverable error: An error that cannot reasonably be reacted to or 11 | recovered from and which indicates a bug e.g. indexing out of bounds. 12 | - Error Type: A type that represents a recoverable error. Error types can 13 | optionally implement the `Error` trait so that it can be reported to the user 14 | or be converted into a trait object. 15 | - Reporting Type: A type that can store all recoverable errors an application 16 | may need to propagate and print them as error reports. 17 | - Reporting types can represent the recoverable errors either via concrete 18 | types, likely parameterized, or trait objects. 19 | - Reporting types often bundle context with errors when they are 20 | constructed, e.g. `Backtrace`. 21 | - Reporting types often provide helper functions for creating ad hoc errors 22 | whose only purpose is to be reported e.g. `anyhow::format_err!` or 23 | `eyre::WrapErr`. 24 | 25 | ### Come to a consensus on current best practices 26 | 27 | Here is a tentative starting point, subject to change: 28 | 29 | - Use `Result` and `Error` types for recoverable errors. 30 | - Use `panic` for unrecoverable errors. 31 | - Implement `Error` for error types that may need to be reported to a human or 32 | be composed with other errors. 33 | - Use enums for types representing multiple failure cases that may need to be 34 | handled. 35 | - For libraries, oftentimes you want to support both reporting and handling 36 | so you implement `Error` on a possibly non-exhaustive enum. 37 | - Error kind pattern for associating context with every enum variant without 38 | including the member in every enum variant. 39 | - Convert to a reporting type when the error is no longer expected to be handled 40 | beyond reporting e.g. `anyhow::Error` or `eyre::Report` or when trait object + 41 | downcast error handling is preferable. 42 | - Recommend `Box`ing concrete error types when stack size is an issue rather 43 | than `Box`ing and converting to `dyn Error`s. 44 | - What is the consensus on handling `dyn Error`s? Should it be encouraged or 45 | discouraged? Should we look into making `Box` implement `Error`? 46 | 47 | 48 | ### Identify pain points in error handling today 49 | 50 | - Backtrace capture is expensive, but without it can be difficult to pinpoint 51 | the origin of errors 52 | - unwrapping errors without first converting to a reporting type will often 53 | discard relevant information 54 | - errors printed from `main` have to assume a prefixed `Error: `, sub-par 55 | control of output format when printing during termination. 56 | - The `Error` trait only exposes three forms of context, can only represent 57 | singly-linked lists for chains of errors 58 | 59 | ### Communicate current best practices 60 | 61 | - Document the consensus. 62 | - Communicate plan for future changes to error handling, and the libraries that 63 | future changes are being based off of. 64 | - Produce learning resources related to current best practices. 65 | - New chapters in the book? 66 | 67 | ### Evaluate options for error reporting type a.k.a. better `Box` 68 | 69 | - Survey the current libraries in the ecosystem: 70 | - `anyhow` 71 | - `eyre` 72 | - Evaluate value of features including: 73 | - Single word width on stack 74 | - Error wrapping with display types and with special downcast support. 75 | - Report hook and configurable `dyn ReportHandler` type for custom report 76 | formats and content, similar to panic handler but for errors. 77 | - `#[no_std]` support 78 | 79 | ### Consolidate ecosystem by merging best practice crates into std 80 | 81 | - Provide a derive macro for `Error` in std. 82 | - Stabilize the `Backtrace` type but possibly not `fn backtrace` on the `Error` 83 | trait. 84 | - Provide necessary API on `Backtrace` to support crates like 85 | `color-backtrace`. 86 | - Move `Error` to core. 87 | - Depends on generic member access. 88 | - Requires resolving downcast dependency on `Box` and blocking the 89 | stabilization of `fn backtrace`. 90 | - Potentially stabilize an error reporting type based on `anyhow` and `eyre` now 91 | that they're close to having identical feature sets. 92 | 93 | ### Add missing features 94 | 95 | - Generic member access on the `Error` trait. 96 | - `Error` return traces: 97 | - Depends on specialization and generic member access. 98 | - Fix rough corners around reporting errors and `Termination`. 99 | 100 | ## Non Goals 101 | 102 | - This group should not be involved in managing design discussions for the `Try` 103 | trait, `try` blocks, or `try` fns. 104 | 105 | ## Membership Requirements 106 | 107 | - Group membership is open, any interested party can participate in discussions, 108 | repeat contributors will be added to appropriate teams. 109 | 110 | ## Additional Questions 111 | 112 | ### What support do you need, and separately want, from the Rust organization? 113 | 114 | I'm not sure, my main concern is getting prompt feedback on RFCs. 115 | 116 | ### Why should this be a project group over a community effort? 117 | 118 | There isn't anything in this project group that can't be handled as a community 119 | effort, but centralizing work into a project group should help speed things. 120 | Error handling is a core aspect of the language and changes in error handling 121 | have large impacts on the ecosystem. Ensuring that efforts to refine error 122 | handling within Rust have sufficient resources and don't stall out is in the 123 | best interests of the community. By organizing efforts as a project group we 124 | will hopefully have an easier time recruiting new members, getting attention on 125 | RFCs from members of the libs team, and using the established resources and 126 | expertise of the rust organization for coordinating our efforts. 127 | 128 | ### What do you expect the relationship to the team be? 129 | 130 | The project group will create RFCs for various changes to the standard library 131 | and the team will review them via the standard RFC process. 132 | 133 | ### Who are the initial shepherds/leaders? (This is preferably 2–3 individuals, but not required.) 134 | 135 | Jane Lusby(@yaahc), Andrew Gallant(@BurntSushi), and Sean Chen(@seanchen1991). 136 | 137 | ### Is your group long-running or temporary? 138 | 139 | Temporary. 140 | 141 | ### If it is temporary, how long do you see it running for? 142 | 143 | This depends pretty heavily on how quickly the RFCs move, anywhere between 6 144 | months and 2 years I'd guess but don't quote me on this. 145 | 146 | ### If applicable, which other groups or teams do you expect to have close contact with? 147 | 148 | Primarily the libs team, but there may be some small interactions with the lang 149 | team, compiler team, and traits working group. 150 | 151 | ### Where do you see your group needing help? 152 | 153 | Primarily in drafting RFCs, writing is not this author's strong suit. 154 | -------------------------------------------------------------------------------- /LICENSE-APACHE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | --------------------------------------------------------------------------------