Pith. sign in

REVIEW 4 major objections 6 minor 44 references

Recommendation of Exception Handling Code in Mobile App Development

T0 review · 4 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read Android exception handling code is learnable: 70% top-1 accuracy on catch types, 89% on repair calls.

desk verdict Useful large-scale exception-handling recommender with sensible core models and an honest cross-validated evaluation, but the headline accuracies measure agreement with existing developer practice rather than verified correctness, and the tool-level threshold tuning is optimistic. read the letter →

arxiv 1908.06567 v1 pith:SYJSIEYX submitted 2019-08-19 cs.SE

Tam The Nguyen , Phong Minh Vu , Tung Thanh Nguyen This is my paper · ORCID
classification cs.SE
keywords exceptionhandlingcoderecommendationAndroidfuzzysettheoryn-gramlanguagemodelmulti-classclassificationAPIusageminingbugdetection
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

This paper tries to show that exception handling code in Android apps is learnable and predictable: given the set of method calls inside a try block, both the exception type to catch and the sequence of repair calls for the catch block can be recommended automatically. The authors build two techniques, XRank and XHand, from a corpus of 4,000 top free Google Play apps containing over 16 million methods. They report that XRank identifies the exception type developers actually caught with 70% top-1 accuracy and 87% top-3 accuracy, while XHand predicts the next repair call with 89% top-1 and 96% top-3 accuracy. These techniques are packaged into ExAssist, an Android Studio and IntelliJ IDEA plugin that can wrap selected code in a try-catch block and suggest repairing calls. If the numbers hold, a code editor could generate catch blocks matching what experienced developers write, reducing crashes and bad practices such as swallowing exceptions.

What carries the argument

The load-bearing mechanism is a pair of statistical models trained from bytecode-represented app code via GROUM, a graph-based object-usage model. XRank uses fuzzy sets: for each method call $m$, a membership function $\mu_m(E) = \frac{|D_m \cap D_E|}{|D_m \cup D_E|}$ measures how often exception $E$ co-occurs with $m$ in try-catch code, and the score for a whole snippet is $\mu_S(E) = 1 - \prod_{m \in S}(1 - \mu_m(E))$. XHand treats repair sequences as sentences: the first repair call is a multi-class classification problem over the try-block method set (J48 decision tree), and later calls come from a 2-gram model with Witten-Bell smoothing. The GROUM extractor turns source and bytecode into typed object-usage graphs so that method calls, exception types, and temporal order of repair calls can be counted.

What would settle it

Take a held-out set of real Android crash reports with known stack traces and independently verified fixes; if XRank's top-1 recommended exception matches the stack-trace exception in substantially fewer than 70% of cases while still matching the original developer-written catch blocks at 70%, then the reported accuracy measures agreement with existing habits rather than the correctness of the recommended catch.

Watch

Extended reading notes

Core claim

The central claim is that, for Android development, the exception type that should be caught and the method calls that should repair the object state are largely determined by the API method calls appearing in the try block. XRank models the association between API methods and exception types as fuzzy sets built from co-occurrence counts in existing try-catch code; ranking by the combined membership score recovers the developer-chosen exception at top-1 in 70% of cases. XHand models repair call sequences as sentences: a multi-class classifier (J48 decision tree) predicts the first repair call from the try-block method set, and an n-gram model with Witten-Bell smoothing predicts the following calls, reaching 89% top-1 accuracy on next-call prediction. In an end-to-end evaluation on 128 real exception bugs, ExAssist detected 116 of them (90.6%) and matched developer repair actions in 27 of 42 fixes.

Load-bearing premise

The approach assumes that the exception type and repair method calls written by developers in existing catch blocks are the correct answer to recommend, even though the paper's own motivating study shows developers often swallow exceptions or fix them with bad practices.

Editorial extensions

If this is right

  • An IDE plugin can flag a risky API call as soon as it is typed, because XRank computes exception scores from the set of method calls in the current snippet without needing the rest of the method.
  • Developers who catch an exception and do nothing can be offered concrete next steps, since XHand predicts the first repair call with 89% top-1 accuracy from the object's try-block context.
  • The learning works without API documentation, because both models are trained from bytecode; undocumented Android exceptions can still be recommended if they co-occur with method calls in existing code.
  • On the reported bug-fix data, the context-aware approach matches developer repairs in 27 of 42 fixes, about four times as many as the frequency-based baseline, suggesting that method-call context rather than global frequency drives exception handling decisions.

Reading between the lines

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

  • If the goal is correctness rather than common practice, the accuracy numbers should be re-measured against crash reports and verified repairs; the paper's ground truth is whatever developers wrote, and the paper itself documents that developers often swallow exceptions.
  • The method is not tied to Android: retraining XRank and XHand on other API-rich ecosystems (for example Kotlin/Native, iOS, or server-side Java) would test whether the same co-occurrence and n-gram signals transfer.
  • A stronger and testable variant would feed data-flow information from the try block into XRank instead of only the flat set of method calls; that could target the 30% of cases where the top-1 exception recommendation misses.
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

4 major / 6 minor

Summary. The paper proposes two techniques for recommending exception handling code in Android app development: XRank, a fuzzy-set-based model that ranks exception types likely to be thrown by a set of method calls in a try block, and XHand, a statistical model (multi-class classification plus an n-gram model) that recommends repairing method call sequences for a catch block. These are integrated into ExAssist, an IntelliJ/Android Studio plugin. The evaluation uses a large dataset of 4,000 Google Play apps, reports top-1/top-3 accuracies of 70%/87% for XRank and 89%/96% for XHand under 10-fold cross-validation, compares against frequency baselines, and additionally evaluates ExAssist on 128 real exception bug fixes and 42 repair fixes.

Significance. If the reported accuracies are robust, the paper would provide strong evidence that exception handling patterns in Android code are highly predictable from the method calls in try blocks, and the tool would be a practically useful aid. The study's strengths include the very large corpus (over 16 million methods), app-level 10-fold cross-validation for the main XRank/XHand experiments, simple and meaningful frequency baselines, and an evaluation on real exception bug fixes. The fuzzy-set formulation in XRank is parameter-free for the ranking step, and the paper makes dataset and tool links available. The central derivation is not circular: model parameters are learned on training folds and tested on held-out folds.

major comments (4)
  1. [Sections V-B, V-C vs. Section II-B] The headline accuracies for XRank and XHand are computed by treating the exception type in each existing developer-written catch block and the repair sequence in each existing catch block as the correct label. However, Section II-B of the same paper reports that developers swallow exceptions in 16% of bug fixes and otherwise 'did not handle exceptions properly.' Agreement with existing practice is therefore not the same as correctness of the recommended code, and the abstract's claim that the techniques recommend 'correct exception handling code' is not directly supported by these experiments. The paper already contains a closer-to-correctness corpus of 128 real exception bug fixes and 42 repair cases; re-running XRank and XHand on that corpus, or otherwise validating the catch-block labels, would directly address this concern.
  2. [Section V-D1, Figure 10, Table V] The 25th-percentile selection threshold for ExAssist's try-catch recommendation is chosen by maximizing F1 on the same 256-sample evaluation set that is then used to report Table V. This is adaptive tuning on the test set, so the reported detection rate of 90.62% and the associated F1 are optimistically biased. The threshold should be selected by nested cross-validation or on a separate validation set, with the final performance reported on untouched data.
  3. [Section V-D1, negative examples] The 128 negative examples are defined as code snippets with no try-catch blocks and no changes in project history. Uncaught runtime exceptions are exactly the class of exception bugs the tool is designed to detect (Section II-A), so the absence of a try-catch block does not imply that the snippet is exception-free. These negative labels are unverified, which biases the reported precision and recall. An independent source of 'no exception expected' labels is needed before the F1 values in Figure 10 and Table V can be taken at face value.
  4. [Section V-D2, Table VI] The repair recommendation evaluation uses only 42 bug fixes, with 27 exact matches and 3 partial matches. At this sample size the 64% figure has wide confidence intervals, and no significance test accompanies the comparison with Barbosa et al. More importantly, the paper's claim 'XHand has 89% top-1 accuracy' is established in Section V-C on existing-code labels, not on this real-fix corpus; reporting how XHand itself performs on the 42 repair cases would connect the headline result to the real-bug evaluation.
minor comments (6)
  1. [Abstract and Section V-B] The Introduction states XRank has top-5 accuracy of 93%, while Section V-B reports 'Top-5 accuracy of XRank model approaches 94%.' These numbers should be reconciled.
  2. [Section V-B] The baseline for XRank is called 'n-gram model' in the text ('the corresponding top-1 and top-3 accuracy of n-gram model are 37%'), but the baseline described is frequency-based. This appears to be a typo and should be corrected to 'frequency baseline.'
  3. [Table V] The rows labeled 'Top-1 accuracy 86', 'Top-2 accuracy 96', and 'Top-3 accuracy 104' report counts, not rates; the table headings should distinguish counts from percentages, and the text should state clearly that these percentages are computed over the 116 detected cases rather than over all 128 bugs.
  4. [Section II and reference [5]] The motivational statistics in Section II rely on reference [5], which is listed as 'Anonymous, Under Review.' A published version or a public dataset should be cited so that the motivating claims are independently verifiable.
  5. [Section III-B] XHand uses a fixed 2-gram model with Witten-Bell smoothing, but no sensitivity analysis is reported for the n-gram order. A brief study of n=2 versus n=3 would strengthen the claim that the chosen configuration is appropriate.
  6. [Global] There are several presentation issues: 'In this session' should be 'In this section' (Section IV), the label 'Thredhold' in Figure 10 should be 'Threshold', and the paper alternates between 'confident score' and 'confidence score' for the same concept.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: XRank and XHand are trained and tested on disjoint folds, and the reported accuracy is held-out agreement with developer-written catch blocks, not a restatement of the training input.

full rationale

The paper's central claims are XRank's top-k exception-type recommendations and XHand's top-k repair-call recommendations (Sections V-B and V-C). XRank's membership scores (Eq. 1) and XHand's n-gram/classifier probabilities (Eqs. 5-6) are estimated from training folds only; the 10-fold cross-validation protocol ('we trained XRank with nine folds then tested XRank on the remaining fold') keeps test caught method sets and (S_n, S_h) pairs out of parameter estimation. The label being predicted (exception type or next repair call) is not the same as the model's input features (method calls in the try block), and no test-set label is used to construct the scoring functions. The 25% threshold in Section V-D is selected by F1 on the bug-detection sample and is a hyper-parameter choice, so it may cause adaptive overfitting but is not a circular derivation. Self-citations to the authors' prior work [5], [11]-[13] supply motivation or off-the-shelf modeling infrastructure (GROUM, n-grams, J48) rather than the predicted quantities; they are not load-bearing for the accuracy claims. The empirical evaluation on 128 bug fixes and 42 repair cases is an external benchmark relative to the 4,000-app training corpus, so the headline numbers are not equivalent to the input data by construction.

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

The models are purely statistical over observed code, so the main epistemic burden is the quality of the ground truth extracted from existing catch blocks and the modeling assumptions (fuzzy union, n-gram Markov). The threshold parameter is fitted to the evaluation set, which is the largest red flag in the ledger.

free parameters (2)
  • Selection threshold (percentile) for try-catch recommendation = 25th percentile
    Chosen by maximizing F1 on the 256-sample detection test set (Figure 10); not evaluated on a separate validation set, so detection results are optimistically biased.
  • N-gram order for XHand = 2
    Fixed at 2-gram with Witten-Bell smoothing following prior code-completion work; not tuned on this dataset, so it is a modeling choice rather than a fitted parameter.
assumptions (5)
  • domain assumption Existing developer-written catch blocks provide correct exception types and repair actions as ground truth.
    The evaluation of XRank and XHand uses these as labels; if many handlers are wrong or swallow exceptions, the measured accuracy is agreement with practice, not correctness.
  • domain assumption The fuzzy union formula (Equation 3) is an appropriate combination of per-method exception associations.
    XRank ranks exceptions with this formula without validating independence assumptions among method calls in a try block.
  • domain assumption Uncaught method sets, i.e., methods outside try blocks, are valid negative evidence that no exception needs catching.
    Used to compute method usage counts in the XRank model; a method may be unguarded because the developer forgot, not because no exception can occur.
  • ad hoc to paper Apps with rating at least 3 (out of 5) have higher quality exception handling code.
    Data collection filters 4,000 apps by rating under this assumption; there is no empirical check that rating correlates with handler quality.
  • domain assumption The repair method call sequence in a catch block follows an n-gram Markov property.
    XHand predicts subsequent repair calls from up to n-1 prior calls, a standard language model assumption applied to code.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Recommendation of Exception Handling Code in Mobile App Development." pith.science (2026). https://pith.science/paper/SYJSIEYX

@misc{pith2026190806567,
  author       = {Pith},
  title        = {Pith review of: Recommendation of Exception Handling Code in Mobile App Development},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SYJSIEYX}},
  note         = {Machine review of arXiv:1908.06567}
}
read the original abstract

In modern programming languages, exception handling is an effective mechanism to avoid unexpected runtime errors. Thus, failing to catch and handle exceptions could lead to serious issues like system crashing, resource leaking, or negative end-user experiences. However, writing correct exception handling code is often challenging in mobile app development due to the fast-changing nature of API libraries for mobile apps and the insufficiency of their documentation and source code examples. Our prior study shows that in practice mobile app developers cause many exception-related bugs and still use bad exception handling practices (e.g. catch an exception and do nothing). To address such problems, in this paper, we introduce two novel techniques for recommending correct exception handling code. One technique, XRank, recommends code to catch an exception likely occurring in a code snippet. The other, XHand, recommends correction code for such an occurring exception. We have developed ExAssist, a code recommendation tool for exception handling using XRank and XHand. The empirical evaluation shows that our techniques are highly effective. For example, XRank has top-1 accuracy of 70% and top-3 accuracy of 87%. XHand's results are 89% and 96%, respectively.

Figures

Figures reproduced from arXiv: 1908.06567 by the authors.

Figure 1
Figure 1. An exception bug fix appears in the Wordpress project In our previous work [5], we performed a detailed empirical study on 246 exception bugs and fixes from 10 Android apps. Table I shows the number of exception bug fixes for each project in our empirical dataset. The dataset is available at rebrand.ly/ExDataset. We discovered several interesting findings on the nature of exception-related bugs in mobile app develop… view at source ↗
Figure 2
Figure 2. An example of swallowing an exception On handling activities, we found that programmers did not perform any actions, i.e. swallowing exceptions, to handle exception in about 16% (40/246) bug fixes. An example of swallowing exception is shown in [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Different types of handling actions Programmers invoke method calls or other actions to handle exceptions in 41.86% (103/246) of bug fixes. We found that about 52% (54/103) of these bug fixes, programmers used de￾fault values to handle exceptions. One example of this handling type is if an exception occurs inside a method that returns an object, in the catch block of the fix, programmers handle exceptions by returni… view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Handling exceptions of HttpURLConnection object In the first usage, the exception may occur while using connecting to a server via connect method. In this situation, we would want to get the error stream by calling getErrorStream to get information about the error for …
Figure 5
Figure 5. Figure 5: shows the design overview of ExAssist. It has five major components including two modules to extract API usage models (represented as graph-based object usage models - GROUM [11]) from source code and bytecode, a module to extract API exception usages from those usage …
Figure 7
Figure 7. Figure 7: Recommending repairing actions Recommending Exception Repairs [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 6
Figure 6. Figure 6: Recommending Exception Types by ExAssist [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 8
Figure 8. Figure 8: The accuracy of XRank 1 2 3 4 5 Top-k 50 60 70 80 90 100 Accuracy (%) XHand Baseline [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

44 extracted references · 34 canonical work pages

  1. [1]

    Finding and preventing run-time error handling mistakes,

    W. Weimer and G. C. Necula, “Finding and preventing run-time error handling mistakes,” in Proceedings of the 19th Annual ACM SIGPLAN Conference on Object-oriented Programming, Systems, Languages, and Applications , ser. OOPSLA ’04. New York, NY , USA: ACM, 2004, pp. 419–431. [Online]. Available: http: //doi.acm.org/10.1145/1028976.1029011

    work page arXiv 2004

  2. [2]

    Api change and fault proneness: A threat to the success of android apps,

    M. Linares-V ´asquez, G. Bavota, C. Bernal-C ´ardenas, M. Di Penta, R. Oliveto, and D. Poshyvanyk, “Api change and fault proneness: A threat to the success of android apps,” in Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering , ser. ESEC/FSE

    work page 2013

  3. [3]

    Undocumented and unchecked: Exceptions that spell trouble,

    M. Kechagia and D. Spinellis, “Undocumented and unchecked: Exceptions that spell trouble,” in Proceedings of the 11th Working Conference on Mining Software Repositories , ser. MSR 2014. New York, NY , USA: ACM, 2014, pp. 312–315. [Online]. Available: http://doi.acm.org/10.1145/2597073.2597089

    arXiv 2014

  4. [4]

    Unveiling exception handling bug hazards in android based on github and google code issues,

    R. Coelho, L. Almeida, G. Gousios, and A. van Deursen, “Unveiling exception handling bug hazards in android based on github and google code issues,” in MSR, 2015

    work page 2015

  5. [5]

    How developers handle exceptions and fix exception bugs in mobile apps?

    Anonymous, “How developers handle exceptions and fix exception bugs in mobile apps?” Under Review . [Online]. Available: http: //rebrand.ly/ExPaper

    work page

  6. [6]

    Unveiling exception handling bug hazards in android based on github and google code issues,

    R. Coelho, L. Almeida, G. Gousios, and A. van Deursen, “Unveiling exception handling bug hazards in android based on github and google code issues,” in Proceedings of the 12th Working Conference on Mining Software Repositories , ser. MSR ’15. Piscataway, NJ, USA: IEEE Press, 2015, pp. 134–145. [Online]. Available: http://dl.acm.org/citation.cfm?id=2820518.2820536

    arXiv 2015

  7. [7]

    G. J. Klir and B. Yuan, Fuzzy Sets and Fuzzy Logic: Theory and Applications. Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 1995

    work page 1995

  8. [8]

    Hastie, R

    T. Hastie, R. Tibshirani, and J. Friedman, The Elements of Statistical Learning. Springer New York Inc., 2001

    work page 2001

Show all 44 references
  1. [9]

    On the naturalness of software,

    A. Hindle, E. T. Barr, Z. Su, M. Gabel, and P. Devanbu, “On the naturalness of software,” in Proceedings of the 34th International Conference on Software Engineering , ser. ICSE ’12. Piscataway, NJ, USA: IEEE Press, 2012, pp. 837–847. [Online]. Available: http://dl.acm.org/cit...

    2012

  2. [10]

    Code completion with statistical language models,

    V . Raychev, M. Vechev, and E. Yahav, “Code completion with statistical language models,” in Proceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation , ser. PLDI ’14. New York, NY , USA: ACM, 2014, pp. 419–428. [Online]. Available: http:...

    2014

  3. [11]

    Graph-based mining of multiple object usage patterns,

    T. T. Nguyen, H. A. Nguyen, N. H. Pham, J. M. Al-Kofahi, and T. N. Nguyen, “Graph-based mining of multiple object usage patterns,” in Proceedings of the the 7th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on The Foundations of So...

    2009

  4. [12]

    Learning api usages from bytecode: A statistical approach,

    T. T. Nguyen, H. V . Pham, P. M. Vu, and T. T. Nguyen, “Learning api usages from bytecode: A statistical approach,” in the 38th International Conference on Software Engineering , ser. ICSE ’16

  5. [13]

    Recommending api usages for mobile apps with hidden markov model,

    ——, “Recommending api usages for mobile apps with hidden markov model,” in Automated Software Engineering (ASE), 2015 30th IEEE/ACM International Conference on , 2015

    2015

  6. [14]

    Graph-based statistical language model for code,

    A. T. Nguyen and T. N. Nguyen, “Graph-based statistical language model for code,” in Proceedings of the 37th International Conference on Software Engineering - Volume 1 , ser. ICSE ’15. Piscataway, NJ, USA: IEEE Press, 2015, pp. 858–868. [Online]. Available: http://dl.acm.org/...

    2015

  7. [15]

    Heuristic strategies for recommendation of exception handling code,

    E. A. Barbosa, A. Garcia, and M. Mezini, “Heuristic strategies for recommendation of exception handling code,” in Brazilian Symposium on Software Engineering , 2012

    2012

  8. [16]

    An exploratory study on exception handling bugs in java programs,

    F. Ebert, F. Castor, and A. Serebrenik, “An exploratory study on exception handling bugs in java programs,” J. Syst. Softw. , vol. 106, no. C, pp. 82–101, Aug. 2015. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2015.04.066

    2015 doi

  9. [17]

    Studying the relationship between exception handling practices and post-release defects,

    G. B. de P ´adua and W. Shang, “Studying the relationship between exception handling practices and post-release defects,” in Proceedings of the 15th International Conference on Mining Software Repositories , ser. MSR ’18. New York, NY , USA: ACM, 2018, pp. 564–575. [Online]. A...

    2018

  10. [18]

    Revisiting exception handling practices with exception flow analysis,

    G. B. d. Pdua and W. Shang, “Revisiting exception handling practices with exception flow analysis,” in 2017 IEEE 17th International Working Conference on Source Code Analysis and Manipulation (SCAM) , Sep. 2017, pp. 11–20

    2017

  11. [19]

    The excep- tion handling riddle: An empirical study on the android api,

    M. Kechagia, M. Fragkoulis, P. Louridas, and D. Spinellis, “The excep- tion handling riddle: An empirical study on the android api,” Journal of Systems and Software , vol. 142, 04 2018

    2018

  12. [20]

    Towards a context dependent java exceptions hierarchy,

    M. Kechagia, T. Sharma, and D. Spinellis, “Towards a context dependent java exceptions hierarchy,” in Proceedings of the 39th International Conference on Software Engineering Companion , ser. ICSE-C ’17. Piscataway, NJ, USA: IEEE Press, 2017, pp. 347–349. [Online]. Available: ...

    2017 doi

  13. [21]

    Discovering faults in idiom-based exception handling,

    M. Bruntink, A. van Deursen, and T. Tourw ´e, “Discovering faults in idiom-based exception handling,” in Proceedings of the 28th International Conference on Software Engineering , ser. ICSE ’06. New York, NY , USA: ACM, 2006, pp. 242–251. [Online]. Available: http://doi.acm.or...

    2006

  14. [22]

    Unveiling exception handling guidelines adopted by java developers,

    H. Melo, R. Coelho, and C. Treude, “Unveiling exception handling guidelines adopted by java developers,” in 2019 IEEE 26th Interna- tional Conference on Software Analysis, Evolution and Reengineering (SANER), Feb 2019, pp. 128–139

    2019

  15. [23]

    On the use of context in recommending exception handling code examples,

    M. M. Rahman and C. K. Roy, “On the use of context in recommending exception handling code examples,” in SCAM, 2014

    2014

  16. [24]

    Global-aware recommendations for repairing violations in exception handling,

    E. A. Barbosa and A. Garcia, “Global-aware recommendations for repairing violations in exception handling,” TSE, 2017

    2017

  17. [25]

    Enforcing exception handling policies with a domain-specific language,

    E. A. Barbosa, A. Garcia, M. P. Robillard, and B. Jakobus, “Enforcing exception handling policies with a domain-specific language,” TSE, 2016

    2016

  18. [26]

    Improving developers awareness of the exception handling policy,

    T. Montenegro, H. Melo, R. Coelho, and E. Barbosa, “Improving developers awareness of the exception handling policy,” inSANER, 2018

    2018

  19. [27]

    Preventing ero- sion in exception handling design using static-architecture conformance checking,

    J. L. M. Filho, L. Rocha, R. Andrade, and R. Britto, “Preventing ero- sion in exception handling design using static-architecture conformance checking,” in Software Architecture, 2017

    2017

  20. [28]

    Expsol: Recommending online threads for exception-related bug reports,

    X. Liu, B. Shen, H. Zhong, and J. Zhu, “Expsol: Recommending online threads for exception-related bug reports,” in 2016 23rd Asia-Pacific Software Engineering Conference (APSEC) , Dec 2016, pp. 25–32

    2016

  21. [29]

    Mining repair model for exception-related bug,

    H. Zhong and H. Mei, “Mining repair model for exception-related bug,” Journal of Systems and Software , vol. 141, pp. 16 – 31,

  22. [30]

    Mining exception-handling rules as sequence association rules,

    S. Thummalapenta and T. Xie, “Mining exception-handling rules as sequence association rules,” in Proceedings of the 31st International Conference on Software Engineering , ser. ICSE ’09, Washington, DC, USA, 2009

    2009

  23. [31]

    Mining temporal specifications for error detection,

    W. Weimer and G. C. Necula, “Mining temporal specifications for error detection,” in Proceedings of the 11th International Conference on Tools and Algorithms for the Construction and Analysis of Systems , ser. TACAS’05, Berlin, Heidelberg, 2005

    2005

  24. [32]

    Fuzzy set-based automatic bug triaging: Nier track,

    A. Tamrawi, T. T. Nguyen, J. Al-Kofahi, and T. N. Nguyen, “Fuzzy set-based automatic bug triaging: Nier track,” in ICSE, 2011

    2011

  25. [33]

    Fuzzy set and cache-based approach for bug triaging,

    A. Tamrawi, T. T. Nguyen, J. M. Al-Kofahi, and T. N. Nguyen, “Fuzzy set and cache-based approach for bug triaging,” in ESEC/FSE, 2011

    2011

  26. [34]

    Fuzzy set approach for automatic tagging in evolving software,

    J. M. Al-Kofahi, A. Tamrawi, T. T. Nguyen, H. A. Nguyen, and T. N. Nguyen, “Fuzzy set approach for automatic tagging in evolving software,” in ICSM, 2010

    2010

  27. [35]

    An automated approach for bug categoriza- tion using fuzzy logic,

    I. Chawla and S. K. Singh, “An automated approach for bug categoriza- tion using fuzzy logic,” in ISEC, 2015

    2015

  28. [36]

    On the localness of software,

    Z. Tu, Z. Su, and P. Devanbu, “On the localness of software,” in Proceedings of the 22Nd ACM SIGSOFT International Symposium on Foundations of Software Engineering , ser. FSE 2014. New York, NY , USA: ACM, 2014, pp. 269–280. [Online]. Available: http://doi.acm.org/10.1145/2635...

    2014

  29. [37]

    Mining source code repositories at mas- sive scale using language modeling,

    M. Allamanis and C. Sutton, “Mining source code repositories at mas- sive scale using language modeling,” in Mining Software Repositories (MSR), 2013 10th IEEE Working Conference on , May 2013, pp. 207– 216

    2013

  30. [38]

    Learning natural coding conventions,

    M. Allamanis, E. T. Barr, C. Bird, and C. Sutton, “Learning natural coding conventions,” in Proceedings of the ACM SigSoft Symposium on Foundations of Software Engineering . ACM Association for Computing Machinery, November 2014. [Online]. Available: http://research.microsoft....

    2014

  31. [39]

    Code template inference using language models,

    F. Jacob and R. Tairas, “Code template inference using language models,” in Proceedings of the 48th Annual Southeast Regional Conference, ser. ACM SE ’10. New York, NY , USA: ACM, 2010, pp. 104:1–104:6. [Online]. Available: http://doi.acm.org.dist.lib.usu.edu/10. 1145/1900008.1900143

    2010

  32. [40]

    Structured generative models of natural source code,

    C. J. Maddison and D. Tarlow, “Structured generative models of natural source code,” in The 31st International Conference on Machine Learning (ICML) , June 2014. [Online]. Available: http://research.microsoft.com/apps/pubs/default.aspx?id=208387

    2014

  33. [41]

    A statistical semantic language model for source code,

    T. T. Nguyen, A. T. Nguyen, H. A. Nguyen, and T. N. Nguyen, “A statistical semantic language model for source code,” in Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering , ser. ESEC/FSE 2013. New York, NY , USA: ACM, 2013, pp. 532–542. [Online]. ...

    2013 doi

  34. [42]

    Graph-based pattern-oriented, context-sensitive source code completion,

    A. Nguyen, T. T. Nguyen, H. A. Nguyen, A. Tamrawi, H. Nguyen, J. Al- Kofahi, and T. Nguyen, “Graph-based pattern-oriented, context-sensitive source code completion,” in Software Engineering (ICSE), 2012 34th International Conference on , June 2012, pp. 69–79

    2012

  35. [2013]

    New York, NY , USA: ACM, 2013, pp. 477–487. [Online]. Available: http://doi.acm.org/10.1145/2491411.2491428

    2013

  36. [2018]

    Available: http://www.sciencedirect.com/science/article/ pii/S0164121218300505

    [Online]. Available: http://www.sciencedirect.com/science/article/ pii/S0164121218300505

Pith tools

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