Fotango Ltd > Froody-42.041_2 > Froody::Error



Annotate this POD


Open  0
View/Report Bugs


Froody::Error - Froody error class


  use Froody::Error qw(err);
  # throw an error
  eval { 
    Froody::Error->throw("user.problem", "user '$userid' not known", $data);

  # "user.problem, user '9BC6DD8C-1E25-11DA-98F1-DDB51046DF9C' not known, "
  print $@->code .", ". $@->msg

  # and a stacktrace
  print $@->stacktrace

  # print the data section
  print Dumper $@->data;
  # check if the error is the right class
  if (err("user"))


Froody::Error is the Froody error class. It's designed to be powerful, yet simple to use. It's a subclass of

Often, the easiest way to create an error response from within Froody is to throw a Froody::Error. This will be caught by the server, and it'll be turned into an error response before dispatching it to the client.

Standard Froody::Error errors that are thrown by Froody itself indicating that something is wrong with Froody (e.g. you've asked for a method that doesn't exist, or you've ommited a required parameter) are listed in Froody::Error::Standard.


To throw an error with Froody::Error you just have to call the throw method with up to three arguments:

  # throw an error with its code, reporting the default message

  # throw an error with its code, reporting a custom message
  Froody::Error->throw("what", "bang");
  # throw an error with code, custome message, and some data
  Froody::Error->throw("what", bang", { thingy => "broken" });

In each case this creates a new Froody::Error object and then dies with it.

The first argument is the code that defines the type of error that we're throwing. The second argument is a message, a string which describes the error. If this error is translated to a Froody error response then these will be mapped to the code and message attributes of the <err> repectivly. The third argument is the data, a set of parameters that decribe in a computer understandable format what causes the error. This data potentially will be transformed into the children of the <err> tag based on what specification is in the errortypes of the repository.

Hierarchal Error Messages

Error messages use 'dot' notation to indicate what error messages are sub-types of other error messages.

For example:

  Froody::Error->throw("io", "Bad IO");

And, a more particular error:

  Froody::Error->throw("io.file", "There was a problem with the file");

And an even more particular error

  Froody::Error->throw("io.file.notfound", "File not found");

But all these methods can be detected with isa_err

  if ($@->isa_err("io")) { ... }

Or even better with the err functions (as this won't go "bang" if $@ is a hashref)

  use Froody::Error qw(err);
  if (err("io")) { ... }


new( message )



Return the error code. Read only.

message / msg / text

Returns the error message. Read only.


Return (a copy of) the error data. Read only.


Returns a string containing both the error code and the error text, and a stacktrace. This is what is returned if you try and use a Froody::Error in string context.


We used to have a different sort of error. Rather than having hierarchal error codes that looked like this:

  <err code="file.rwerr" message="unable to write to disk" />

We used to use simple numbers and have errors that looked like this:

  <err code="12" message="unable to write to disk" />

This is fine. The key here to remember is that numbered error codes are a subset of the hierarchal error codes. The numbers are all just top level errors that are made up of alphanumerics that are just digits. It's just a not very hierarchal hierarchal error code.


None known.

Please report any bugs you find via the CPAN RT system.


Copyright Fotango 2005. All rights reserved.

Please see the main Froody documentation for details of who has worked on this project.

This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself.


Froody::Error::Standard, Froody::Response::Error

syntax highlighting: