Pith. sign in

REVIEW 5 major objections 5 minor 52 references

Seeker: Towards Exception Safety Code Generation with Intermediate Language Agents Framework

T0 review · 5 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Seeker claims that a five-agent pipeline backed by a curated Java exception knowledge base can make LLM-generated code substantially more robust at handling exceptions, reporting state-of-the-art scores on every metric it tests.

desk verdict Plausible multi-agent framework for exception safety, but the SOTA claim rests on unvalidated LLM-judge metrics and a self-filtered dataset; worth a serious referee, not worth citing yet. read the letter →

arxiv 2412.11713 v1 pith:I3CYI6CS submitted 2024-12-16 cs.CL cs.SE

Xuanming Zhang , Yuxuan Chen , Yiming Zheng , Zhexin Zhang , Yuan Yuan , Minlie Huang This is my paper · ORCID
classification cs.CLcs.SE
keywords exceptionhandlingLLMcodegenerationmulti-agentframeworkretrieval-augmentedJavarobustnessautomatedreviewCommonEnumeration
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Seeker argues that the weak exception handling found in both human-written and LLM-generated code can be repaired systematically by decomposing the job into five specialized agents, each mirroring a step of what skilled developers actually do: scan, detect fragile code, retrieve relevant exception knowledge, rank handling strategies, and write the fix. The paper reports that this pipeline, supported by a curated Common Exception Enumeration (CEE) of Java exceptions, lifts automated code-review scores from 0.21 for general prompting to 0.85 and code-review pass rates from 24% to 92% on 750 fragile Java snippets drawn from real projects. If the results hold, the framework offers a drop-in robustness layer for existing code LLMs, addressing a defect class that ordinary correctness benchmarks ignore. The paper also positions this as the first systematic study of using LLMs specifically to improve exception safety in realistic code.

What carries the argument

The machinery has three parts. The Common Exception Enumeration (CEE) is a structured Java exception hierarchy derived from JDK documentation plus enterprise and open-source practices; each of its nodes stores Scenario, Property, and Handling Logic so that a code context can be matched to a recommended catch strategy. Deep-RAG is a retrieval algorithm for inheritance-heavy knowledge: it assigns development-scenario labels to branches of the exception tree, uses few-sample verification to refine those labels via feedback, then evaluates nodes by depth to pull out relevant exception handling guidance. The five agents (Planner, Detector, Predator, Ranker, Handler) wrap these components into a chain of thought: segmentation, static-plus-semantic detection of fragile code, CEE retrieval, scoring of candidate exceptions, and final try-catch generation.

What would settle it

Have the same 750 test snippets and baseline outputs scored by a panel of human Java engineers blind to method, or by an LLM judge architecturally far from GPT-4o. If Seeker's CRS lead over FuzzyCatch and Nexgen shrinks sharply under that independent judge while the objective detection metrics (COV, COV-P, ACC) stay as reported, the headline robustness advantage would be a judge-preference artifact rather than improved exception handling.

Watch

Extended reading notes

Core claim

The paper's central claim is that exception handling quality in LLM-generated code is not primarily a function of model size but of structured knowledge and task decomposition. Seeker operationalizes this by breaking exception handling into detection, retrieval, ranking, and repair, and by feeding each stage a hand-curated hierarchy of 433 Java exception nodes annotated with typical scenarios, properties, and recommended handling logic. On its 750-snippet Java benchmark, the full framework achieves ACRS 0.85, COV 91%, COV-P 81%, ACC 79%, ES 0.64, and CRS 92%, beating general prompting, traditional RAG, the knowledge-driven prompting baseline KPC, FuzzyCatch, and Nexgen on all six metrics. Ablation tables are used to show every agent earns its place, with the Handler contributing the largest CRS drop when removed (92% to 42%) and the CEE knowledge base contributing the largest overall drop (ACRS 0.85 to 0.38 without it). The paper further claims the framework extends beyond snippets: on 50 exception-related SWE-bench issues it raises the resolve rate from 19% to 26% over a baseline agent, and on CoderEval Java generation it raises Codex's Pass@1 from 27.83% to 38.16%.

Load-bearing premise

The reported state-of-the-art results rest on treating the automated and LLM-based code review scores (ACRS and CRS) as unbiased measures of exception-handling quality, even though the same family of model that writes the code also grades much of it, so a stylistic preference for Seeker's output would inflate the gap over baselines.

Editorial extensions

If this is right

  • If the reported numbers are correct, Seeker establishes a new state of the art for automated exception handling in Java, with the largest gains on code review scores (CRS 92% vs. 24% for general prompting and 52% for the next-best baseline).
  • The ablation pattern implies that robustness gains come from the orchestration plus the knowledge base, not from any single component: dropping the Handler halves the CRS, and dropping CEE halves ACRS.
  • Because Seeker is described as model-agnostic, it should transfer to other code LLMs and, with maintained documentation, to other languages, a generalization the paper claims but does not yet demonstrate.
  • The framework's applicability to repository-level tasks would mean exception handling can be improved during real issue resolution, not just on isolated snippets.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • In our reading, the most direct test the paper invites is a judge swap: the CRS metric uses GPT-4o as the reviewer while GPT-4o also produces Seeker's best outputs, so an independent human panel or a differently styled judge could narrow the reported gap even if the underlying code is objectively better.
  • If the CEE-style knowledge base is the real driver, then comparable robustness gains should be obtainable in languages with different error models, such as Python exceptions or Rust's Result types, by building an analogous typed hierarchy of error scenarios and handling strategies.
  • Deep-RAG's branch-labeling and few-shot verification loop is a general recipe for retrieval over any taxonomic knowledge, so a natural follow-up is benchmarking it against flat RAG on non-exception hierarchies with known inheritance structure.
  • The constant-overhead parallelization result suggests a cheap deployment, which makes a plausible next experiment an end-to-end study of developer acceptance and maintenance burden on real pull requests rather than snippet-level metrics.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. The paper studies exception handling in LLM-generated Java code. It identifies three failure modes—insensitive detection of fragile code, inaccurate capture of exception blocks, and distorted handling solutions—and proposes Seeker, a five-agent framework (Planner, Detector, Predator, Ranker, Handler) supported by a curated Common Exception Enumeration (CEE) and a Deep-RAG retrieval algorithm. The experiments report very large gains over baselines on 750 Java snippets, an ablation study over agents, a comparison across base LLMs, and auxiliary results on SWE-bench and CoderEval. The abstract, introduction, and conclusion claim that Seeker sets a new state of the art in exception handling.

Significance. If the reported results were fully validated, Seeker would be a practically useful contribution to LLM-based code generation: it decomposes exception handling into interpretable subtasks, integrates a structured exception knowledge base, proposes a deep retrieval method for inheritance hierarchies, and provides public code and CEE URLs. The paper also contains usable prompt templates, an agent ablation, and a model-comparison study. However, the central SOTA claim rests on two unvalidated judge-based metrics, a self-filtered ground-truth set, and point estimates without statistical tests. The contribution is therefore significant only conditionally; the evaluation must be strengthened before the paper can support its main claim.

major comments (5)
  1. [A.3.1 (ACRS and CRS definitions)] The two headline metrics cannot support the SOTA claim in their current form. ACRS is defined as a weighted average over an unnamed 'automated code review model' with no tool name, rule set, or validation, and CRS is a binary good/bad judgment from GPT-4o with no rubric, no inter-annotator agreement, and no comparison to human expert review. Since Seeker's best configuration in Table 6 also uses GPT-4o as the generator, the reported 92% versus 24% gap may reflect stylistic affinity with the judge rather than exception-handling quality. Please validate these metrics against human expert annotations or runtime behavior, and report per-item agreement.
  2. [A.3.2 (dataset construction)] COV, COV-P, ACC, and ES are computed against 'actual' sensitive segments, try-blocks, exception types, and try-catch text obtained by manually filtering GitHub commits. The filtering procedure is not quantified (no inter-rater reliability), the gold annotations are not released, and using human post-fix code as ground truth conflicts with the paper's own observation in A.1 that a large fraction of human exception-handling blocks violate established best practices. This undermines the more objective-looking metrics as well.
  3. [Table 1 and Figure 5] All central comparisons are single point estimates without confidence intervals, standard errors, or significance tests, despite N=750 snippets. Statements such as 'significantly' and 'stable' in Section 4.2 are not backed by statistics, and the ablation margins in Table 2 are likewise untested. Please provide interval estimates or paired tests and per-item distributions rather than one average per condition.
  4. [Table 1 with B.1] The baseline comparison is not sufficiently controlled. The paper does not state whether all baselines in Table 1 use the same underlying LLM as Seeker, and the related-work discussion identifies Neurex as a closely related learning-based exception-handling method but explicitly excludes it from the experiments. Without matched base models and a stronger LLM-only baseline (e.g., GPT-4o with the same prompting budget), the claimed state-of-the-art over prior specialized tools is not established.
  5. [Algorithms 1 and 2 (parameters)] The framework depends on free parameters alpha, beta, and gamma in Algorithm 1 and theta, delta, and D in Algorithm 2, but the paper never reports their values or a sensitivity analysis. This leaves the exact reproducibility of the reported numbers incomplete and weakens the claim of generalizability across codebases and base models.
minor comments (5)
  1. [A.2.1 and throughout] The term 'Fraile code' appears repeatedly; it should be 'fragile code'.
  2. [Section 1 contribution list] The bullet defining CEE says 'Contextual Exception Engineering' while the abstract, Section 3.1, and elsewhere define CEE as 'Common Exception Enumeration'; please standardize the acronym expansion.
  3. [Algorithm 1, line 29] The pseudo-code 'foreach exception eik of E′ni if gik > γdo' is malformed; please rewrite it as a conditional statement inside the loop.
  4. [A.3.3 prompt templates] The prompt templates contain typos such as 'discription' and some JSON placeholders have unbalanced braces; please proofread them.
  5. [A.4 SWE-bench experiments] The selection of 50 SWE-bench issues 'related to exception handling' is not described; please state the selection procedure and, ideally, report results on a defined random sample or the full Lite set.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation found; the CRS/ACRS judge overlap is a measurement-validity concern, not a by-construction reduction.

full rationale

Seeker's pipeline is empirically assembled from external knowledge (CEE built from JDK documentation and open-source practice) and from agent prompts, and its reported gains are measurements against baselines under the paper's own metrics. I checked for steps where an output is identical to an input by definition. The ACRS formula is a weighted average over an unspecified automated code review model; the CRS formula is a binary judgment by an LLM-based reviewer (e.g., GPT-4o). Neither formula references Seeker's own outputs as the definition of the metric, so no quantity is equal to its own premise by construction. The overlap between GPT-4o as the underlying base model and as the CRS judge is a genuine threat to the validity of the SOTA claim, but it is an empirical bias rather than a circular step: the paper never fits a parameter to the CRS value, nor does it define 'good' as 'generated by GPT-4o'. Deep-RAG's few-shot label refinement uses pass/capture feedback, but the appendix does not state that these few-shot samples come from the evaluation set, so claiming test-set fitting would be speculation rather than a demonstrated circularity. The dataset's use of human post-fix code as gold is in tension with the paper's own premise that human exception handling is often flawed, but that is a benchmark-validity issue, not a circular derivation. The large CEE-ablation drop suggests the knowledge base contributes independent signal beyond any judge preference. There is no load-bearing self-citation and no imported uniqueness theorem in the derivation chain. Accordingly, no specific reduction can be quoted, and the circularity score is 0.

Assumptions & free parameters 5 free parameters · 4 assumptions · 2 invented entities

The method relies on several free design parameters (ranking weights, thresholds, segmentation limits) that are not reported, and on the correctness of the CEE and the ground-truth snippets. The central claim is empirical, so the most load-bearing assumptions are about evaluation validity rather than about mathematical derivations.

free parameters (5)
  • alpha (likelihood weight) in Ranker grading = not reported
    Algorithm 1 line 26 computes g_ik = alpha * likelihood + beta * suitability, but the weights are not given and no sensitivity analysis is reported.
  • beta (suitability weight) = not reported
    Same equation as alpha; no value or tuning procedure is reported.
  • gamma (handling threshold) = not reported
    Algorithm 1 line 29 applies a handling strategy only if g_ik > gamma; the threshold is unspecified.
  • Planner unit length limit = 200 lines
    The Planner prompt in A.3.3 hardcodes 'length within 200 lines' as a segmentation criterion; no sensitivity analysis is provided.
  • Deep-RAG thresholds (theta, delta) and depth D = not reported
    Algorithm 2 uses thresholds on pass rate, capture accuracy, and relevance, plus a depth D, but no values or sensitivity analysis are given.
assumptions (4)
  • domain assumption The hand-built CEE correctly represents the Java exception hierarchy and best-practice handling logic.
    CEE is constructed from JDK docs and 'enterprise insights' via LLM generation and RL fine-tuning (A.2.2). The paper provides no systematic validation that the scenario, property, and handling annotations are correct.
  • domain assumption The 750 actual exception-handling blocks extracted from selected GitHub repos are correct ground truth.
    Sections 4.1.1 and A.3.2 describe semi-automated selection based on 'potential for exception handling improvements'. There is no inter-rater reliability or independent verification that these blocks represent good practice.
  • domain assumption try-catch is the preferred exception handling mechanism and is the only technique considered.
    A.2.1 states try-catch blocks 'represent the most practical and common approach' and the framework is built around them, ignoring throws/throw alternatives that may be better in some contexts.
  • domain assumption The LLM-based judges (ACRS, CRS) measure exception handling quality without bias.
    CRS uses GPT-4o as judge, and ACRS uses an unspecified automated code review model. No validation is provided that these scores correlate with human expert judgment.
invented entities (2)
  • Common Exception Enumeration (CEE) independent evidence
    purpose: Curated knowledge base of Java exceptions with scenario, property, and handling logic, used to ground retrieval and generation.
    The paper provides a community URL and describes the resource, so it can be inspected independently. However, the evaluation does not isolate whether incorrect CEE entries would degrade performance.
  • Intermediate Language (IL) agents
    purpose: A framing for the agent pipeline that interprets code through an intermediate representation to improve exception handling; not a concrete new formal language.
    The paper uses 'IL' as a label for the agent pipeline but does not specify a formal intermediate language. It functions as terminology rather than a new proposed entity.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Seeker: Towards Exception Safety Code Generation with Intermediate Language Agents Framework." pith.science (2026). https://pith.science/paper/I3CYI6CS

@misc{pith2026241211713,
  author       = {Pith},
  title        = {Pith review of: Seeker: Towards Exception Safety Code Generation with Intermediate Language Agents Framework},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/I3CYI6CS}},
  note         = {Machine review of arXiv:2412.11713}
}
read the original abstract

In real world software development, improper or missing exception handling can severely impact the robustness and reliability of code. Exception handling mechanisms require developers to detect, capture, and manage exceptions according to high standards, but many developers struggle with these tasks, leading to fragile code. This problem is particularly evident in open-source projects and impacts the overall quality of the software ecosystem. To address this challenge, we explore the use of large language models (LLMs) to improve exception handling in code. Through extensive analysis, we identify three key issues: Insensitive Detection of Fragile Code, Inaccurate Capture of Exception Block, and Distorted Handling Solution. These problems are widespread across real world repositories, suggesting that robust exception handling practices are often overlooked or mishandled. In response, we propose Seeker, a multi-agent framework inspired by expert developer strategies for exception handling. Seeker uses agents: Scanner, Detector, Predator, Ranker, and Handler to assist LLMs in detecting, capturing, and resolving exceptions more effectively. Our work is the first systematic study on leveraging LLMs to enhance exception handling practices in real development scenarios, providing valuable insights for future improvements in code reliability.

Figures

Figures reproduced from arXiv: 2412.11713 by the authors.

Figure 1
Figure 1. Overview of the Intermediate Lan￾guage (IL) agents (Right) Compared with Tra￾ditional Code Generation Approaches (Left) in Exception-Safe Code Generation Tasks The Seeker framework leverages IL agents to perform dynamic analysis, transformation, and optimiza￾tion of code to ensure robust exception handling. In contrast, traditional approaches often rely on static error-handling routines and lack comprehen￾sive analy… view at source ↗
Figure 2
Figure 2. (a) Comparison of LLM and human exception handling performance as prompts evolve from [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Comprehensive Workflow of Seeker. Seeker orchestrates the automated exception handling process through the seamless collaboration of five specialized agents: Planner, Detector, Predator, Ranker, and Handler. The colored circles within the workflow illustrate the flow of information and interactions among the agents, highlighting how each component activates and contributes to the overall exception handling process. … view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: An overview of the CEE construction process. The diagram illustrates how authorita￾tive documentation (JDK), enterprise-level best practices, and real-world code repositories are in￾tegrated and refined. Each exception node is en￾riched with Scenario, Property, and Han…
Figure 5
Figure 5. Figure 5: Comparison of Performance Stability Across Baselines and Our Method over Varying Conditions. [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Aligning developers’ exception handling from biased, user-oriented practices to industry [PITH_FULL_IMAGE:figures/full_fig_p012_6.png]
Figure 7
Figure 7. Figure 7: A schematic depiction of integrating the Seeker multi-agent framework into APP requirement [PITH_FULL_IMAGE:figures/full_fig_p025_7.png]
Figure 8
Figure 8. Figure 8: A schematic illustration of the preliminary phenomenon, showing how incremental, targeted [PITH_FULL_IMAGE:figures/full_fig_p029_8.png]
Figure 9
Figure 9. Figure 9: A schematic illustration of the preliminary phenomenon, demonstrating that incremental, [PITH_FULL_IMAGE:figures/full_fig_p030_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

52 extracted references · 42 canonical work pages

  1. [1]

    Yuchen Cai, Aashish Yadavally, Abhishek Mishra, Genesis Montejo, and Tien N. Nguyen. 2024. Programming assistant for exception handling with codebert. In ICSE

    work page 2024

  2. [2]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374

    arXiv 2021

  3. [3]

    Clade. 2023. https://www.anthropic.com/index/claude-2

    work page 2023

  4. [4]

    Caroline Claus and Craig Boutilier. 1998. The dynamics of reinforcement learning in cooperative multiagent systems. In AAAI

    work page 1998

  5. [5]

    Codex. 2021. https://openai.com/index/openai-codex/

    work page 2021

  6. [6]

    de P \' a dua and Weiyi Shang

    Guilherme B. de P \' a dua and Weiyi Shang. 2017. Revisiting exception handling practices with exception flow analysis. In SCAM

    work page 2017

  7. [7]

    Maia, Lincoln S

    D \^ e mora Bruna Cunha de Sousa, Paulo Henrique M. Maia, Lincoln S. Rocha, and Windson Viana. 2020. Studying the evolution of exception handling anti-patterns in a long-lived large-scale project. J. Braz. Comput. Soc

    work page 2020

  8. [8]

    Yihong Dong, Xue Jiang, Zhi Jin, and Ge Li. 2023. Self-collaboration code generation via chatgpt. ACM Trans. Softw. Eng. Methodol

    work page 2023

Show all 52 references
  1. [9]

    an exploratory study on exception handling bugs in java programs

    Felipe Ebert, Fernando Castor, and Alexander Serebrenik. 2020. A reflection on "an exploratory study on exception handling bugs in java programs". In SANER

    2020

  2. [10]

    GPT-3. 2022. https://platform.openai.com/docs/models/gpt-base

    2022

  3. [11]

    GPT-3.5. 2023. https://platform.openai.com/docs/models/\#gpt-3-5-turbo

    2023

  4. [12]

    GPT-4. 2023. https://platform.openai.com/docs/models/gpt-4

    2023

  5. [13]

    GPT-4o. 2024. https://platform.openai.com/docs/models/gpt-4o

    2024

  6. [14]

    Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Y. Wu, Y. K. Li, et al. 2024. Deepseek-coder: When the large language model meets programming - the rise of code intelligence. arXiv preprint arXiv:2401.14196

    2024 arXiv

  7. [15]

    Jingxuan He and Martin T. Vechev. 2023. Large language models for code: Security hardening and adversarial testing. In CCS

    2023

  8. [16]

    Kai Huang, Jian Zhang, Xiangxin Meng, and Yang Liu. 2025. Template-Guided Program Repair in the Era of Large Language Models . In ICSE

    2025

  9. [17]

    Bart Jacobs and Frank Piessens. 2009. Failboxes: Provably safe exception handling. In ECOOP

    2009

  10. [18]

    Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R

    Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R. Narasimhan. 2024. Swe-bench: Can language models resolve real-world github issues? In ICLR

    2024

  11. [19]

    Guohao Li, Hasan Abed Al Kader Hammoud, Hani Itani, Dmitrii Khizbullin, and Bernard Ghanem. 2023 a . Camel: Communicative agents for "mind" exploration of large language model society. In NeurIPS

    2023

  12. [20]

    Jia Li, Ge Li, Yunfei Zhao, Yongmin Li, Huanyu Liu, Hao Zhu, Lecheng Wang, Kaibo Liu, Zheng Fang, Lanshen Wang, et al. 2024 a . Deveval: A manually-annotated code generation benchmark aligned with real-world code repositories. In ACL(Findings)

    2024

  13. [21]

    Junjie Li, Fazle Rabbi, Cheng Cheng, Aseem Sangalay, Yuan Tian, and Jinqiu Yang. 2024 b . An exploratory study on fine-tuning large language models for secure code generation. arXiv preprint 2408.09078

    2024

  14. [22]

    Junjie Li, Aseem Sangalay, Cheng Cheng, Yuan Tian, and Jinqiu Yang. 2024 c . Fine tuning large language model for secure code generation. In FORGE

    2024

  15. [23]

    Kaixuan Li, Jian Zhang, Sen Chen, Han Liu, Yang Liu, and Yixiang Chen. 2024 d . Patchfinder: A two-phase approach to security patch tracing for disclosed vulnerabilities in open-source software. In ISSTA

    2024

  16. [24]

    Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, Chenghao Mou, Marc Marone, Christopher Akiki, Jia Li, Jenny Chim, et al. 2023 b . Starcoder: may the source be with you! TMLR

    2023

  17. [25]

    Xiangwei Li, Xiaoning Ren, Yinxing Xue, Zhenchang Xing, and Jiamou Sun. 2023 c . Prediction of vulnerability characteristics based on vulnerability description and prompt learning. In SANER

    2023

  18. [26]

    Ziyang Luo, Can Xu, Pu Zhao, Qingfeng Sun, Xiubo Geng, Wenxiang Hu, Chongyang Tao, Jing Ma, Qingwei Lin, and Daxin Jiang. 2024. Wizardcoder: Empowering code large language models with evol-instruct. In ICLR

    2024

  19. [27]

    Marvin Minsky. 2007. The emotion machine: Commonsense thinking, artificial intelligence, and the future of the human mind. Simon and Schuster

    2007

  20. [28]

    Suman Nakshatri, Maithri Hegde, and Sahithi Thandra. 2016. Analysis of exception handling patterns in java projects: an empirical study. In MSR

    2016

  21. [29]

    Tam Nguyen, Phong Vu, and Tung Nguyen. 2020 a . Code recommendation for exception handling. In ESEC/FSE

    2020

  22. [30]

    Tam Nguyen, Phong Vu, and Tung Nguyen. 2020 b . Code recommendation for exception handling. In ESEC/FSE

    2020

  23. [31]

    OpenAI o1. 2024. https://platform.openai.com/docs/models/o1

    2024

  24. [32]

    Haidar Osman, Andrei Chis, Jakob Schaerer, Mohammad Ghafari, and Oscar Nierstrasz. 2017. On the evolution of exception usage in java projects. In SANER

    2017

  25. [33]

    Xiaoxue Ren, Xinyuan Ye, Dehai Zhao, Zhenchang Xing, and Xiaohu Yang. 2023. From misuse to mastery: Enhancing code generation with knowledge-driven AI chaining. In ASE

    2023

  26. [34]

    Baptiste Rozi \` e re, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, J \' e r \' e my Rapin, et al. 2023. Code llama: Open foundation models for code. arXiv preprint arXiv:2308.12950

    2023 arXiv

  27. [35]

    Yongliang Shen, Kaitao Song, Xu Tan, Dongsheng Li, Weiming Lu, and Yueting Zhuang. 2023. Hugginggpt: Solving AI tasks with chatgpt and its friends in huggingface. NeurIPS

    2023

  28. [36]

    Mohammed Latif Siddiq and Joanna C. S. Santos. 2022. Securityeval dataset: Mining vulnerability examples to evaluate machine learning-based code generation techniques. In MSR4P&S

    2022

  29. [37]

    Stephen W. Smoliar. 1991. Marvin minsky, the society of mind. Artif. Intell., 48(3):349--370

    1991

  30. [38]

    Wei Tao, Yucheng Zhou, Wenqiang Zhang, and Yu Cheng. 2024. MAGIS: llm-based multi-agent framework for github issue resolution. arXiv preprint 2403.17927

    2024 arXiv

  31. [39]

    Yanlin Wang, Tianyue Jiang, Mingwei Liu, Jiachi Chen, and Zibin Zheng. 2024. Beyond functional correctness: Investigating coding style inconsistencies in large language models. arXiv preprint 2407.00456

    2024 arXiv

  32. [40]

    Westley Weimer and George C. Necula. 2004. Finding and preventing run-time error handling mistakes. In OOPSLA

    2004

  33. [41]

    Zhang, and Qing Liao

    Xin - Cheng Wen, Yupan Chen, Cuiyun Gao, Hongyu Zhang, Jie M. Zhang, and Qing Liao. 2023. Vulnerability detection with graph simplification and enhanced graph representation learning. In ICSE

    2023

  34. [42]

    Chenfei Wu, Shengming Yin, Weizhen Qi, Xiaodong Wang, Zecheng Tang, and Nan Duan. 2023. Visual chatgpt: Talking, drawing and editing with visual foundation models. arXiv preprint 2303.04671

    2023 arXiv

  35. [43]

    Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press

    John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. Swe-agent: Agent-computer interfaces enable automated software engineering

    2024

  36. [44]

    Hao Yu, Bo Shen, Dezhi Ran, Jiaxin Zhang, Qi Zhang, Yuchi Ma, Guangtai Liang, Ying Li, Qianxiang Wang, and Tao Xie. 2024. Codereval: A benchmark of pragmatic code generation with generative pre-trained models. In ICSE

    2024

  37. [45]

    Hao Zhang, Ji Luo, Mengze Hu, Jun Yan, Jian Zhang, and Zongyan Qiu. 2023. Detecting exception handling bugs in C++ programs. In ICSE

    2023

  38. [46]

    Jian Zhang, Xu Wang, Hongyu Zhang, Hailong Sun, Yanjun Pu, and Xudong Liu. 2020. Learning to handle exceptions. In ASE

    2020

  39. [47]

    Kechi Zhang, Jia Li, Ge Li, Xianjie Shi, and Zhi Jin. 2024 a . Codeagent: Enhancing code generation with tool-integrated agent systems for real-world repo-level coding challenges. In ACL

    2024

  40. [48]

    Yifan Zhang, Yang Yuan, and Andrew Chi-Chih Yao. 2024 b . On the diagram of thought. arXiv preprint 2409.10038

    2024 arXiv

  41. [49]

    Xing, et al

    Lianmin Zheng, Wei - Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, et al. 2023. Judging llm-as-a-judge with mt-bench and chatbot arena. In NeurIPS

    2023

  42. [50]

    Jian Zhou, Hongyu Zhang, and David Lo. 2012. Where should the bugs be fixed? more accurate information retrieval-based bug localization based on bug reports. In ICSE

    2012

  43. [51]

    URL: " 'urlintro :=

    ENTRY address author booktitle chapter edition editor howpublished institution journal key month note number organization pages publisher school series title type volume year eprint doi pubmed url lastchecked label extra.label sort.label short.list INTEGERS output.state before...

  44. [52]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 gl...

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.