Skip to content

[Feature Request] Flexible Error/Exception handling #5914

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
4 tasks done
vakrilov opened this issue Jun 5, 2018 · 1 comment
Closed
4 tasks done

[Feature Request] Flexible Error/Exception handling #5914

vakrilov opened this issue Jun 5, 2018 · 1 comment
Assignees
Milestone

Comments

@vakrilov
Copy link
Contributor

vakrilov commented Jun 5, 2018

The Problem

Currently, when an unhandled exception is thrown in NativeScript (inside app-code, core-modules or plugins) it will (in most) cases crash the application showing the error and stack trace.

When in development - in many cases this is what you'd expect. You would want to have the stack-trace of the exact location the unexpected behavior has occurred, so that you can more easily understand what happened and fix it.

However, in production, an application crash can seriously hurt you application credibility and drive away customers. In many cases you might prefer anything else (app freeze, blank screen, failed navigation etc.) to an actual crash with an error log. There are even cases, in whitch the application will recover and will work OK even if something unexpected has happened - for exampled failed animation or a typo in CSS property.

Proposal

The aim of this FR is to propose an API that provides a way to handle errors in different ways in development and in production. It should provide flexibility to configure how errors should be handled. For example:

  1. (development 1) Throw exceptions as soon as error occurs.
  2. (development 2) Show a scary console.log with ERROR: Something bad happened but continue execution of the app. You will see it in you terminal, but decide if it is critical based on what happens with the app after that.
  3. (production) Send an error report to your analytics/error-report server, but continue app execution. Maybe triggers some recover logic that will handle the app without a crash.

API Proposal

Extend the trace module with an error() method.

Use the method in core-framework/plugins/app code:

function doSomething(arg) {
  // Instead of   
  if(!arg) throw new Error("Arg not provided in "doSomething");
  
  // Use trace.error()
  if(!arg) {
    trace.error("Arg not provided in "doSomething");
    return;
  }
  // ... implementation using arg
}

Developers can define custom error handler logic (probably on app startup):

const errorHandler: ErrorHandler = {
    handleError(err){
        //(development 1)
        throw err;

        //(development 2)
        trace.write(err, "unhandlede-error", type.error);

        //(production)
        reportToAnalytics(err)
    }
}

trace.setErrorHandler(errorHandler)

Next Steps

  • Gather FB on this proposal and implement it in the tns-core-modules.
  • Create a comprehensive guide on how to use the error API in the contributing.md. Update: here it is.
  • Require all PRs to follow the guide and handle errors in a similar fashion
  • (ongoing) Gradually refactor most problematic areas of the codebase to use comply with the guides and use this approach (PRs will be welcome).

Ping @NathanWalker @EddyVerbruggen

@vakrilov vakrilov changed the title [FR] Flexible Error/Exception handling [Feature Request] Flexible Error/Exception handling Jun 5, 2018
@vakrilov vakrilov self-assigned this Jun 5, 2018
@vakrilov vakrilov added this to the 4.2 (TBD) milestone Jun 5, 2018
@vakrilov vakrilov closed this as completed Jul 3, 2018
@ghost ghost removed the feature label Jul 3, 2018
@lock
Copy link

lock bot commented Aug 26, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Aug 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants