Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Pig Wiki" for change 
notification.

The following page has been changed by SanthoshSrinivasan:
http://wiki.apache.org/pig/PigDeveloperCookbook

------------------------------------------------------------------------------
  
  There are several types of errors in Pig:
  
-  * '''User Errors'''. This includes invalid syntax, working with non-existent 
data, referring to non-existent relationships, etc. The desired behavior should 
be to show a meaningful error message to the user and abort the processing. 
(This does not mean that in the interactive shell we exit though.)
   * '''Internal Errors'''. This are internal problems with pig code that would 
be handled with `asserts` in languages like C/C++. An example would be a 
unchecked NULL pointer. The desired behavior is to notify the user of the 
failure and to log the stack trace to the client side log file.
-  * '''Frontend Errors'''. This are the errors that occur on the Pig client. 
An example is for instance failure to connect to HOD or access metadata 
repository when we add support for that. The proper behavior in this case would 
be to retry a few times and then to the same handling as for `Internal Errors`.
+  * '''Frontend Errors'''. This are the errors that occur on the Pig client. 
An example is for instance failure to connect to HOD or access metadata 
repository when we add support for that. The proper behavior in this case would 
be to retry a few times and then to the same handling as for `Internal Errors`. 
A special case of Frontend errors is User Errors
+   * '''User Errors'''. This includes invalid syntax, working with 
non-existent data, referring to non-existent relationships, etc. The desired 
behavior should be to show a meaningful error message to the user and abort the 
processing. (This does not mean that in the interactive shell we exit though.)
   * '''Backend Errors'''. This are the errors that happened on the backend 
during the course of the program execution. An example would be failure to read 
a DFS file. The desired behavior in this case is to propagate the error from 
the backend to the frontend and then perform the processing similar to the 
internal error.
  
  It is helpful to be able to separate different types of errors in our code. 
Here is the proposal on how to handle them:
  
-  * For `User Errors`, throw `ParseException` that contains meaningful 
message. For batch and interactive processing, catch the exception in Grunt and 
log the exception message to stderr. The same can be done with the developer in 
the embedded case. In debug mode, log the exception stack into the client side 
log.
-  * For `Internal Errors`, throw `!RuntimeException` or its derivation. Catch 
the exception in main, log it, including the stack, to the client side log. 
Write failure message to stderr pointing to the log file.
+  * For `Internal Errors`, throw `RuntimeException` or its derivation. Catch 
the exception in main, log it, including the stack, to the client side log. 
Write failure message to stderr pointing to the log file.
+ 
   * For `Frontend Errors`, throw `FrontendException` or a subclass of 
`FrontendException`. Catch the exception in main, log it, including the stack, 
to the client side log. Write failure message to stderr pointing to the log 
file. The front-end consists of multiple components - parser, type checker, 
optimizer, translators, etc. All the errors from these components can be 
categorized as front-end errors. Components that are part of the front end will 
throw specific exceptions that capture the context. For example, the parser 
throws a `ParseException`, the type checker will throw a 
`TypeCheckerException`, etc. A list of the exceptions thrown in the front-end 
are as follows.
  
-    1. `FrontendException` Generic front-end exception (subclass of 
`PigException`)
+    1. `FrontendException` Generic front-end exception (subclass of 
`PigException`). Also used for indicating semantic errors and to wrap user 
errors from generated class `ParseException`
     1. `JobCreationException` Used for indicating errors during Map Reduce job 
creation (subclass of `FrontendException`)
     1. `LogicalToPhysicalTranslatorException` Used for indicating errors 
during logical plan to physical plan translation (subclass of 
`VisitorException`)
     1. `MRCompilerException` Used for indicating errors during map reduce plan 
compilation from physical plan (subclass of `VisitorException`)
     1. `OptimizerException` Used for indicating errors during logical plan 
optimization (subclass of `FrontendException`)
+    1. `OptimizerException` Parser generated class. Used for indicating syntax 
errors
     1. `PigException` Generic exception in Pig (subclass of `IOException` and 
the superclass of all exceptions in Pig)
     1. `PlanException` Used for indicating errors during plan/graph operations 
(subclass of `FrontendException`)
     1. `PlanValidationException` Used for indicating errors during plan 
validation (subclass of `VisitorException`)
     1. `SchemaMergeException` Used for indicating errors during schema merges 
(subclass of `FrontendException`)
     1. `TypeCheckerException` Used for indicating errors due to type checking 
(subclass of `VisitorException`)
     1. `VisitorException` Generic exception used for indicating errors when 
visiting a plan (subclass of `FrontendException`)
+ 
+   * For `User Errors`, throw `ParseException` that contains meaningful 
message. Wrap the `ParseException` in the generic `FrontendException` and 
rethrow it. For batch and interactive processing, catch the exception in Grunt 
and log the exception message to stderr. The same can be done with the 
developer in the embedded case. In debug mode, log the exception stack into the 
client side log.
  
   
   * For `Backend Errors` there will need to be backend specific way to get the 
error from the backend to the frontend. Once this is done, log the error into 
client side log file and throw `ExecuteException`. Catch the exception in main, 
log it, including the stack, to the client side log. Write failure message to 
stderr pointing to the log file.

Reply via email to