1compile(3)                 Erlang Module Definition                 compile(3)
2
3
4

NAME

6       compile - Erlang Compiler
7

DESCRIPTION

9       This  module  provides an interface to the standard Erlang compiler. It
10       can generate either a new file, which  contains  the  object  code,  or
11       return a binary, which can be loaded directly.
12

EXPORTS

14       env_compiler_options()
15
16              Return  compiler  options  given  via  the  environment variable
17              ERL_COMPILER_OPTIONS. If the value is a list, it is returned  as
18              is. If it is not a list, it is put into a list.
19
20       file(File)
21
22              Is  the  same  as file(File, [verbose,report_errors,report_warn‐
23              ings]).
24
25       file(File, Options) -> CompRet
26
27              Types:
28
29                 CompRet = ModRet | BinRet | ErrRet
30                 ModRet = {ok,ModuleName} | {ok,ModuleName,Warnings}
31                 BinRet = {ok,ModuleName,Binary} | {ok,ModuleName,Binary,Warn‐
32                 ings}
33                 ErrRet = error | {error,Errors,Warnings}
34
35              Compiles  the  code  in the file File, which is an Erlang source
36              code file without the  .erl  extension.  Options  determine  the
37              behavior of the compiler.
38
39              Returns  {ok,ModuleName}  if  successful,  or error if there are
40              errors. An object code file is created if the  compilation  suc‐
41              ceeds  without  errors.  It  is considered to be an error if the
42              module name in the source code is not the same as  the  basename
43              of the output file.
44
45              Available options:
46
47                basic_validation:
48                  This option is a fast way to test whether a module will com‐
49                  pile successfully. This is useful for code  generators  that
50                  want  to  verify  the code that they emit. No code is gener‐
51                  ated. If warnings are enabled,  warnings  generated  by  the
52                  erl_lint  module  (such as warnings for unused variables and
53                  functions) are also returned.
54
55                  Use option strong_validation to generate all  warnings  that
56                  the compiler would generate.
57
58                strong_validation:
59                  Similar  to  option  basic_validation. No code is generated,
60                  but more compiler passes are run  to  ensure  that  warnings
61                  generated  by the optimization passes are generated (such as
62                  clauses that will not match, or expressions that are guaran‐
63                  teed to fail with an exception at runtime).
64
65                binary:
66                  The  compiler returns the object code in a binary instead of
67                  creating an object file. If successful, the compiler returns
68                  {ok,ModuleName,Binary}.
69
70                bin_opt_info:
71                  The  compiler  will emit informational warnings about binary
72                  matching optimizations (both successful  and  unsuccessful).
73                  For  more information, see the section about bin_opt_info in
74                  the Efficiency Guide.
75
76                {compile_info, [{atom(), term()}]}:
77                  Allows compilers built on top of  compile  to  attach  extra
78                  compilation metadata to the compile_info chunk in the gener‐
79                  ated beam file.
80
81                  It is advised for compilers to remove all  non-deterministic
82                  information  if the deterministic option is supported and it
83                  was supplied by the user.
84
85                compressed:
86                  The compiler will compress the generated object code,  which
87                  can be useful for embedded systems.
88
89                debug_info:
90
91
92                  Includes  debug  information in the form of  Erlang Abstract
93                  Format in the debug_info chunk of the compiled beam  module.
94                  Tools  such  as  Debugger, Xref, and Cover require the debug
95                  information to be included.
96
97                  Warning: Source code can be  reconstructed  from  the  debug
98                  information.     Use     encrypted     debug     information
99                  (encrypt_debug_info) to prevent this.
100
101                  For details, see beam_lib(3).
102
103                {debug_info, {Backend, Data}}:
104
105
106                  Includes custom debug information in the form of  a  Backend
107                  module  with  custom  Data  in the compiled beam module. The
108                  given module must implement a debug_info/4 function  and  is
109                  responsible  for  generating different code representations,
110                  as described in the debug_info under beam_lib(3).
111
112                  Warning: Source code can be  reconstructed  from  the  debug
113                  information.     Use     encrypted     debug     information
114                  (encrypt_debug_info) to prevent this.
115
116                {debug_info_key,KeyString}:
117
118
119                {debug_info_key,{Mode,KeyString}}:
120
121
122                  Includes debug information, but encrypts it so that it  can‐
123                  not  be  accessed without supplying the key. (To give option
124                  debug_info as well is allowed,  but  not  necessary.)  Using
125                  this  option is a good way to always have the debug informa‐
126                  tion available during testing,  yet  protecting  the  source
127                  code.
128
129                  Mode is the type of crypto algorithm to be used for encrypt‐
130                  ing the debug information. The default  (and  currently  the
131                  only) type is des3_cbc.
132
133                  For details, see beam_lib(3).
134
135                encrypt_debug_info:
136
137
138                  Similar  to  the  debug_info_key option, but the key is read
139                  from an .erlang.crypt file.
140
141                  For details, see beam_lib(3).
142
143                deterministic:
144                  Omit the options and source tuples in the list  returned  by
145                  Module:module_info(compile),  and  reduce the paths in stack
146                  traces to the module name alone. This option  will  make  it
147                  easier to achieve reproducible builds.
148
149                makedep:
150                  Produces  a  Makefile rule to track headers dependencies. No
151                  object file is produced.
152
153                  By default, this rule is written to  <File>.Pbeam.  However,
154                  if  option binary is set, nothing is written and the rule is
155                  returned in Binary.
156
157                  For example, if you have the following module:
158
159                -module(module).
160
161                -include_lib("eunit/include/eunit.hrl").
162                -include("header.hrl").
163
164                  The Makefile rule generated by this option looks as follows:
165
166                module.beam: module.erl \
167                  /usr/local/lib/erlang/lib/eunit/include/eunit.hrl \
168                  header.hrl
169
170                makedep_side_effect:
171                  The dependecies are created as a side effect to  the  normal
172                  compilation  process.  This  means that the object file will
173                  also be produced. This option override the makedep option.
174
175                {makedep_output, Output}:
176                  Writes generated rules to  Output  instead  of  the  default
177                  <File>.Pbeam. Output can be a filename or an io_device(). To
178                  write to stdout, use standard_io. However, if binary is set,
179                  nothing  is  written to Output and the result is returned to
180                  the caller with {ok, ModuleName, Binary}.
181
182                {makedep_target, Target}:
183                  Changes the name of the rule emitted to Target.
184
185                makedep_quote_target:
186                  Characters in Target special to make(1) are quoted.
187
188                makedep_add_missing:
189                  Considers missing headers as generated files and  adds  them
190                  to the dependencies.
191
192                makedep_phony:
193                  Adds a phony target for each dependency.
194
195                'P':
196                  Produces  a  listing of the parsed code, after preprocessing
197                  and parse transforms, in the file <File>.P. No  object  file
198                  is produced.
199
200                'E':
201                  Produces a listing of the code, after all source code trans‐
202                  formations have been performed, in  the  file  <File>.E.  No
203                  object file is produced.
204
205                'S':
206                  Produces  a  listing  of  the  assembler  code  in  the file
207                  <File>.S. No object file is produced.
208
209                report_errors/report_warnings:
210                  Causes errors/warnings to be printed as they occur.
211
212                report:
213                  A short form for both report_errors and report_warnings.
214
215                return_errors:
216                  If  this  flag  is  set,  {error,ErrorList,WarningList}   is
217                  returned when there are errors.
218
219                return_warnings:
220                  If this flag is set, an extra field, containing WarningList,
221                  is added to the tuples returned on success.
222
223                warnings_as_errors:
224                  Causes warnings to be treated as errors. This option is sup‐
225                  ported since R13B04.
226
227                return:
228                  A short form for both return_errors and return_warnings.
229
230                verbose:
231                  Causes  more verbose information from the compiler, describ‐
232                  ing what it is doing.
233
234                {source,FileName}:
235                  Overrides  the  source  file  name  as  presented  in   mod‐
236                  ule_info(compile) and stack traces.
237
238                {outdir,Dir}:
239                  Sets a new directory for the object code. The current direc‐
240                  tory is used for output, except when a  directory  has  been
241                  specified with this option.
242
243                export_all:
244                  Causes all functions in the module to be exported.
245
246                {i,Dir}:
247                  Adds  Dir  to  the  list  of directories to be searched when
248                  including  a  file.  When  encountering   an   -include   or
249                  -include_lib  directive,  the  compiler  searches for header
250                  files in the following directories:
251
252                  * ".", the current working directory of the file server
253
254                  * The base name of the compiled file
255
256                  * The directories specified using option  i;  the  directory
257                    specified last is searched first
258
259                {d,Macro}:
260
261
262                {d,Macro,Value}:
263                  Defines  a  macro Macro to have the value Value. Macro is of
264                  type atom, and Value can be any term. The default  Value  is
265                  true.
266
267                {parse_transform,Module}:
268                  Causes the parse transformation function Module:parse_trans‐
269                  form/2 to be applied to the parsed code before the  code  is
270                  checked for errors.
271
272                from_asm:
273                  The  input  file  is  expected to be assembler code (default
274                  file suffix ".S"). Notice that the format of assembler files
275                  is not documented, and can change between releases.
276
277                from_core:
278                  The  input  file  is  expected to be core code (default file
279                  suffix ".core"). Notice that the format of core files is not
280                  documented, and can change between releases.
281
282                no_spawn_compiler_process:
283                  By default, all code is compiled in a separate process which
284                  is terminated at  the  end  of  compilation.  However,  some
285                  tools,  like Dialyzer or compilers for other BEAM languages,
286                  may already manage their own worker processes  and  spawning
287                  an extra process may slow the compilation down. In such sce‐
288                  narios, you can pass this option to stop the  compiler  from
289                  spawning an additional process.
290
291                no_strict_record_tests:
292                  This option is not recommended.
293
294                  By    default,    the    generated    code   for   operation
295                  Record#record_tag.field verifies that the tuple  Record  has
296                  the  correct size for the record, and that the first element
297                  is the tag record_tag. Use this option to omit the verifica‐
298                  tion code.
299
300                no_error_module_mismatch:
301                  Normally the compiler verifies that the module name given in
302                  the source code is the same as the base name of  the  output
303                  file  and  refuses  to generate an output file if there is a
304                  mismatch. If you have a good reason (or  other  reason)  for
305                  having  a  module  name  unrelated to the name of the output
306                  file, this option disables that verification (there will not
307                  even be a warning if there is a mismatch).
308
309                {no_auto_import,[{F,A}, ...]}:
310                  Makes  the  function  F/A no longer being auto-imported from
311                  the erlang module, which resolves  BIF  name  clashes.  This
312                  option  must be used to resolve name clashes with BIFs auto-
313                  imported before R14A, if it is  needed  to  call  the  local
314                  function  with the same name as an auto-imported BIF without
315                  module prefix.
316
317            Note:
318                As from R14A and forward, the compiler resolves calls  without
319                module  prefix  to  local  or imported functions before trying
320                with auto-imported BIFs. If the BIF is to be called,  use  the
321                erlang  module prefix in the call, not {no_auto_import,[{F,A},
322                ...]}.
323
324
325                  If this option is written in the source code, as a  -compile
326                  directive,  the syntax F/A can be used instead of {F,A}, for
327                  example:
328
329                -compile({no_auto_import,[error/1]}).
330
331                no_auto_import:
332                  Do not auto-import any functions from erlang module.
333
334                no_line_info:
335                  Omits line number information to produce a slightly  smaller
336                  output file.
337
338                {extra_chunks, [{binary(), binary()}]}:
339                  Pass  extra chunks to be stored in the .beam file. The extra
340                  chunks must be a list of tuples with a four byte  binary  as
341                  chunk name followed by a binary with the chunk contents. See
342                  beam_lib for more information.
343
344              If warnings are turned on (option report_warnings described ear‐
345              lier),  the following options control what type of warnings that
346              are generated. Except from {warn_format,Verbosity}, the  follow‐
347              ing options have two forms:
348
349                * A warn_xxx form, to turn on the warning.
350
351                * A nowarn_xxx form, to turn off the warning.
352
353              In the descriptions that follow, the form that is used to change
354              the default value are listed.
355
356                {warn_format, Verbosity}:
357                  Causes warnings to be emitted for malformed  format  strings
358                  as arguments to io:format and similar functions.
359
360                  Verbosity selects the number of warnings:
361
362                  * 0 = No warnings
363
364                  * 1 = Warnings for invalid format strings and incorrect num‐
365                    ber of arguments
366
367                  * 2 = Warnings also when the validity cannot be checked, for
368                    example, when the format string argument is a variable.
369
370                  The default verbosity is 1. Verbosity 0 can also be selected
371                  by option nowarn_format.
372
373                nowarn_bif_clash:
374                  This option is removed, it generates a fatal error if used.
375
376            Warning:
377                As from beginning with R14A, the compiler no longer calls  the
378                auto-imported  BIF if the name clashes with a local or explic‐
379                itly imported function, and a  call  without  explicit  module
380                name  is  issued.  Instead,  the local or imported function is
381                called. Still accepting nowarn_bif_clash would make  a  module
382                calling  functions  clashing  with  auto-imported BIFs compile
383                with both the old and new compilers, but with completely  dif‐
384                ferent semantics. This is why the option is removed.
385
386                The  use  of  this option has always been discouraged. As from
387                R14A, it is an error to use it.
388
389                To resolve BIF clashes,  use  explicit  module  names  or  the
390                {no_auto_import,[F/A]} compiler directive.
391
392
393                {nowarn_bif_clash, FAs}:
394                  This option is removed, it generates a fatal error if used.
395
396            Warning:
397                The  use  of  this option has always been discouraged. As from
398                R14A, it is an error to use it.
399
400                To resolve BIF clashes,  use  explicit  module  names  or  the
401                {no_auto_import,[F/A]} compiler directive.
402
403
404                nowarn_export_all:
405                  Turns  off  warnings  for  uses  of  the  export_all option.
406                  Default is to emit a warning if option  export_all  is  also
407                  given.
408
409                warn_export_vars:
410                  Emits   warnings   for  all  implicitly  exported  variables
411                  referred to after  the  primitives  where  they  were  first
412                  defined.  By  default,  the compiler only emits warnings for
413                  exported variables referred to in a pattern.
414
415                nowarn_shadow_vars:
416                  Turns off  warnings  for  "fresh"  variables  in  functional
417                  objects  or  list  comprehensions with the same name as some
418                  already defined variable. Default is to  emit  warnings  for
419                  such variables.
420
421                nowarn_unused_function:
422                  Turns off warnings for unused local functions. Default is to
423                  emit warnings for all local functions that  are  not  called
424                  directly or indirectly by an exported function. The compiler
425                  does not include unused local  functions  in  the  generated
426                  beam  file,  but  the  warning  is  still useful to keep the
427                  source code cleaner.
428
429                {nowarn_unused_function, FAs}:
430                  Turns  off  warnings  for  unused   local   functions   like
431                  nowarn_unused_function  does,  but  only  for  the mentioned
432                  local functions. FAs is a tuple {Name,Arity} or  a  list  of
433                  such tuples.
434
435                nowarn_deprecated_function:
436                  Turns  off  warnings  for  calls  to  deprecated  functions.
437                  Default is to emit warnings for every  call  to  a  function
438                  known by the compiler to be deprecated. Notice that the com‐
439                  piler does not know about attribute -deprecated(), but  uses
440                  an  assembled list of deprecated functions in Erlang/OTP. To
441                  do a more general check, the Xref tool can be used. See also
442                  xref(3)  and  the function xref:m/1, also accessible through
443                  the function c:xm/1.
444
445                {nowarn_deprecated_function, MFAs}:
446                  Turns off warnings for calls to  deprecated  functions  like
447                  nowarn_deprecated_function  does, but only for the mentioned
448                  functions. MFAs is a tuple {Module,Name,Arity} or a list  of
449                  such tuples.
450
451                nowarn_deprecated_type:
452                  Turns  off  warnings for use of deprecated types. Default is
453                  to emit warnings for every use of a type known by  the  com‐
454                  piler to be deprecated.
455
456                nowarn_removed:
457                  Turns  off  warnings  for  calls to functions that have been
458                  removed. Default is to emit warnings for  every  call  to  a
459                  function known by the compiler to have been recently removed
460                  from Erlang/OTP.
461
462                {nowarn_removed, ModulesOrMFAs}:
463                  Turns off warnings for calls to modules  or  functions  that
464                  have  been  removed.  Default  is to emit warnings for every
465                  call to a function  known  by  the  compiler  to  have  been
466                  recently removed from Erlang/OTP.
467
468                nowarn_obsolete_guard:
469                  Turns  off warnings for calls to old type testing BIFs, such
470                  as pid/1 and list/1. See the Erlang Reference Manual  for  a
471                  complete  list  of  type  testing BIFs and their old equiva‐
472                  lents. Default is to emit warnings for  calls  to  old  type
473                  testing BIFs.
474
475                warn_unused_import:
476                  Emits  warnings for unused imported functions. Default is to
477                  emit no warnings for unused imported functions.
478
479                nowarn_unused_vars:
480                  By default,  warnings  are  emitted  for  unused  variables,
481                  except  for  variables beginning with an underscore ("Prolog
482                  style warnings"). Use this option to turn off this  kind  of
483                  warnings.
484
485                nowarn_unused_record:
486                  Turns  off  warnings  for unused record types. Default is to
487                  emit warnings for unused locally defined record types.
488
489              Another class of warnings is generated by  the  compiler  during
490              optimization  and code generation. They warn about patterns that
491              will never match (such as a=b), guards that always  evaluate  to
492              false, and expressions that always fail (such as atom+42).
493
494              Those warnings cannot be disabled (except by disabling all warn‐
495              ings).
496
497          Note:
498              The compiler does not warn for  expressions  that  it  does  not
499              attempt to optimize. For example, the compiler tries to evaluate
500              1/0, detects that it will cause an exception, and emits a  warn‐
501              ing.  However,  the compiler is silent about the similar expres‐
502              sion, X/0, because of the variable in  it.  Thus,  the  compiler
503              does  not  even  try to evaluate and therefore it emits no warn‐
504              ings.
505
506
507          Warning:
508              The absence of warnings does not mean that there are no  remain‐
509              ing errors in the code.
510
511
512          Note:
513              All  options,  except  the  include  path ({i,Dir}), can also be
514              given  in  the  file  with   attribute   -compile([Option,...]).
515              Attribute -compile() is allowed after the function definitions.
516
517
518          Note:
519              Before OTP 22, the option {nowarn_deprecated_function, MFAs} was
520              only recognized when given in  the  file  with  attribute  -com‐
521              pile(). (The option {nowarn_unused_function,FAs} was incorrectly
522              documented to only work in a file, but it also worked when given
523              in  the option list.) Starting from OTP 22, all options that can
524              be given in the file can also be given in the option list.
525
526
527              For debugging of the compiler, or for pure curiosity, the inter‐
528              mediate  code  generated by each compiler pass can be inspected.
529              To print a complete list of the options to produce  list  files,
530              type  compile:options()  at the Erlang shell prompt. The options
531              are printed in the order that the passes are executed.  If  more
532              than one listing option is used, the one representing the earli‐
533              est pass takes effect.
534
535              Unrecognized options are ignored.
536
537              Both WarningList and ErrorList have the following format:
538
539              [{FileName,[ErrorInfo]}].
540
541              ErrorInfo is described later in this section.  The  filename  is
542              included  here,  as  the  compiler uses the Erlang pre-processor
543              epp, which allows the code to be included in other files. It  is
544              therefore  important to know to which file the line number of an
545              error or a warning refers.
546
547       forms(Forms)
548
549              Is the same as forms(Forms,  [verbose,report_errors,report_warn‐
550              ings]).
551
552       forms(Forms, Options) -> CompRet
553
554              Types:
555
556                 Forms = [Form]
557                 CompRet = BinRet | ErrRet
558                 BinRet  = {ok,ModuleName,BinaryOrCode} | {ok,ModuleName,Bina‐
559                 ryOrCode,Warnings}
560                 BinaryOrCode = binary() | term()
561                 ErrRet = error | {error,Errors,Warnings}
562
563              Analogous to file/1, but takes a list of forms  (in  the  Erlang
564              abstract format representation) as first argument. Option binary
565              is implicit, that is, no  object  code  file  is  produced.  For
566              options  that  normally produce a listing file, such as 'E', the
567              internal format for that compiler pass (an Erlang term,  usually
568              not a binary) is returned instead of a binary.
569
570       format_error(ErrorDescriptor) -> chars()
571
572              Types:
573
574                 ErrorDescriptor = errordesc()
575
576              Uses  an  ErrorDescriptor  and returns a deep list of characters
577              that describes  the  error.  This  function  is  usually  called
578              implicitly  when  an  ErrorInfo  structure (described in section
579              Error Information) is processed.
580
581       output_generated(Options) -> true | false
582
583              Types:
584
585                 Options = [term()]
586
587              Determines whether the compiler generates a beam file  with  the
588              given  options.  true means that a beam file is generated. false
589              means that the compiler generates some listing file,  returns  a
590              binary, or merely checks the syntax of the source code.
591
592       noenv_file(File, Options) -> CompRet
593
594              Works like file/2, except that the environment variable ERL_COM‐
595              PILER_OPTIONS is not consulted.
596
597       noenv_forms(Forms, Options) -> CompRet
598
599              Works  like  forms/2,  except  that  the  environment   variable
600              ERL_COMPILER_OPTIONS is not consulted.
601
602       noenv_output_generated(Options) -> true | false
603
604              Types:
605
606                 Options = [term()]
607
608              Works like output_generated/1, except that the environment vari‐
609              able ERL_COMPILER_OPTIONS is not consulted.
610

DEFAULT COMPILER OPTIONS

612       The (host operating system) environment  variable  ERL_COMPILER_OPTIONS
613       can be used to give default compiler options. Its value must be a valid
614       Erlang term. If the value is a list, it is used as is. If it is  not  a
615       list, it is put into a list.
616
617       The  list is appended to any options given to file/2, forms/2, and out‐
618       put_generated/2.   Use   the   alternative   functions    noenv_file/2,
619       noenv_forms/2, or noenv_output_generated/2 if you do not want the envi‐
620       ronment variable to be consulted, for example, if you are  calling  the
621       compiler recursively from inside a parse transform.
622
623       The list can be retrieved with env_compiler_options/0.
624

INLINING

626       The compiler can do function inlining within an Erlang module. Inlining
627       means that a call to a function is replaced with the function body with
628       the  arguments  replaced with the actual values. The semantics are pre‐
629       served, except if exceptions are generated in the inlined code.  Excep‐
630       tions  are  reported  as occurring in the function the body was inlined
631       into.  Also,  function_clause  exceptions  are  converted  to   similar
632       case_clause exceptions.
633
634       When  a  function  is  inlined,  the original function is kept if it is
635       exported (either by an explicit export or if the option export_all  was
636       given) or if not all calls to the function are inlined.
637
638       Inlining does not necessarily improve running time. For example, inlin‐
639       ing can increase Beam stack use, which probably is detrimental to  per‐
640       formance for recursive functions.
641
642       Inlining  is  never  default. It must be explicitly enabled with a com‐
643       piler option or a -compile() attribute in the source module.
644
645       To enable inlining, either use the option inline to  let  the  compiler
646       decide  which  functions  to  inline, or {inline,[{Name,Arity},...]} to
647       have the compiler inline all calls  to  the  given  functions.  If  the
648       option  is  given  inside  a  compile  directive  in  an Erlang module,
649       {Name,Arity} can be written as Name/Arity.
650
651       Example of explicit inlining:
652
653       -compile({inline,[pi/0]}).
654
655       pi() -> 3.1416.
656
657
658       Example of implicit inlining:
659
660       -compile(inline).
661
662       The option {inline_size,Size} controls how  large  functions  that  are
663       allowed  to  be  inlined.  Default  is  24, which keeps the size of the
664       inlined code roughly the same as the  un-inlined  version  (only  rela‐
665       tively small functions are inlined).
666
667       Example:
668
669       %% Aggressive inlining - will increase code size.
670       -compile(inline).
671       -compile({inline_size,100}).
672

INLINING OF LIST FUNCTIONS

674       The  compiler  can also inline various list manipulation functions from
675       the module list in STDLIB.
676
677       This feature must be explicitly enabled with a  compiler  option  or  a
678       -compile() attribute in the source module.
679
680       To enable inlining of list functions, use option inline_list_funcs.
681
682       The following functions are inlined:
683
684         * lists:all/2
685
686         * lists:any/2
687
688         * lists:foreach/2
689
690         * lists:map/2
691
692         * lists:flatmap/2
693
694         * lists:filter/2
695
696         * lists:foldl/3
697
698         * lists:foldr/3
699
700         * lists:mapfoldl/3
701
702         * lists:mapfoldr/3
703

PARSE TRANSFORMATIONS

705       Parse  transformations  are  used when a programmer wants to use Erlang
706       syntax but with different semantics. The original Erlang code  is  then
707       transformed into other Erlang code.
708

ERROR INFORMATION

710       The  ErrorInfo  mentioned  earlier is the standard ErrorInfo structure,
711       which is returned from all I/O modules. It has the following format:
712
713       {ErrorLine, Module, ErrorDescriptor}
714
715       ErrorLine is the atom none if the error does not correspond to  a  spe‐
716       cific line, for example, if the source file does not exist.
717
718       A string describing the error is obtained with the following call:
719
720       Module:format_error(ErrorDescriptor)
721

SEE ALSO

723       epp(3), erl_id_trans(3), erl_lint(3), beam_lib(3)
724
725
726
727Ericsson AB                     compiler 7.4.9                      compile(3)
Impressum