@@ -207,6 +207,46 @@ file in the `benchmarks` folder and the PR will generate the benchmark on demand
207207GitHub Actions CI as described below before merging. Note that it will use the Project.toml and Manifest.toml of the subfolder, so
208208any changes to dependencies requires that those are updated.
209209
210+ ### Handling Method Omissions and Errors in Benchmarks
211+
212+ It is good practice to include sections showing * why* a method was omitted from a
213+ benchmark — for example, because it errors or is too slow. This gives readers useful
214+ context about solver coverage and limitations.
215+
216+ However, these error demonstrations ** must be captured** so they don't break the build.
217+ By default, any code chunk that throws an uncaught error will fail the benchmark build.
218+ This is intentional: it catches real issues instead of silently including ugly stacktraces
219+ in published output.
220+
221+ There are two ways to safely demonstrate errors:
222+
223+ ** Option 1: Use a ` try/catch ` block** (preferred when you want to show a friendly message):
224+
225+ ```` markdown
226+ ``` julia
227+ try
228+ sol = solve (prob, SomeMethod ())
229+ catch e
230+ println (" SomeMethod failed: " , e)
231+ end
232+ ```
233+ ````
234+
235+ ** Option 2: Use the ` error=true ` chunk option** (when you want to show the actual error output):
236+
237+ ```` markdown
238+ ``` julia; error=true
239+ sol = solve(prob, SomeMethod())
240+ ```
241+ ````
242+
243+ ** Do not** leave raw uncaught errors in benchmark code. They will:
244+ 1 . Fail the CI build
245+ 2 . Produce ugly stacktrace output if the chunk somehow runs
246+
247+ When adding a new solver comparison that you expect to fail, always wrap it in one of the
248+ above patterns.
249+
210250### Reporting Bugs and Issues
211251
212252Report any bugs or issues at [ the SciMLBenchmarks repository] ( https://github.com/SciML/SciMLBenchmarks.jl ) .
0 commit comments