البحث في الموقع

في الدرسين السابقين ألقينا نظرة عامة حول التحقيقات في Active Record وتعرّفنا على مساعدات التحقيقات وتعرّفنا أيضًا على الخيارات الشائعة وأنواع التحقيقات وسنتابع في هذا الدرس ما تبقى من هذا الدليل التعليمي . 6 أداء/تنفيذ تحقيقات مخصّصة Performing Custom Validations عندما لا تكون التحقيقات المدمجة كافية لاحتياجاتك يمكنك كتابة محققاتك الخاصّة أو وسائل تحقيق كما تفضّل. 6.1 المحققات المخصّصة Custom Validators المحققات المخصصة عبارة عن فئات تقتبس من ActiveModel::Validator. تلك الأصناف يجب أن تنفّذ وسيلة validate التي تأخذ سجل كـتعبير و تُؤدّي التحقيق عليه. يُستدعى المحقق الخاص باستخدام وسيلة validates_with. class MyValidator < ActiveModel::Validator def validate(record) unless record.name.starts_with? 'X' record.errors[:name] << 'Need a name starting with X please!' end end end class Person include ActiveModel::Validations validates_with MyValidator end أسهل طريقة لإضافة محققات مخصّصة للتحقق من خصائص شخصيّة تكون ب ActiveModel::EachValidator مناسب. في هذه الحالة يجب أن ينفّذ المتحقق الخاص وسيلة validate_each ، التي تأخذ ثلاثة تعبيرات: سجل و خاصّية و قيمة. يتم إدارتهم مع ما يناسبهم: الخاصّية يتم التحقق منها ، و قيمة الخاصّية يتم تجاوزها. class EmailValidator < ActiveModel::EachValidator def validate_each(record, attribute, value) unless value =~ /\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/i record.errors[attribute] << (options[:message] || "is not an email") end end end class Person < ApplicationRecord validates :email, presence: true, email: true end كما هو موضّح بالمثال يمكن دمج(ربط) محقّقات أساسيّة بمحقّقاتك الخاصّة. 6.2 الوسائل المخصّصة يمكنك أيضًا إنشاء وسائل تؤكّد على حالة النموذج و تضيف رسائل إلى الـ errorscollection عندما يكونوا غير صالحين. يجب أن تسجّل بعد ذلك تلك الوسائل باستخدام فئة (validate (API ، مرورًا بالرموز الخاصة بأسماء وسائل التحقيق. يمكنك تمرير(إرسال) أكثر من رمز واحد لكل وسيلة لفئة و سيجري التحقيقات المخصصة في نفس الترتيب الذي سُجّلوا به. وسيلة ?valid سوف تؤكّد أن مجموعة الأخطاء فارغة، لذلك يجب أن تضيف تحقيقاتك المخصّصة أخطاء إليها عندما ترغب أن يفشل التحقيق. class Invoice < ApplicationRecord validate :expiration_date_cannot_be_in_the_past, :discount_cannot_be_greater_than_total_value def expiration_date_cannot_be_in_the_past if expiration_date.present? && expiration_date < Date.today errors.add(:expiration_date, "can't be in the past") end end def discount_cannot_be_greater_than_total_value if discount > total_value errors.add(:discount, "can't be greater than total value") end end end كما هي مضبُوطة افتراضيّا ، سوف تعمل هذه التحقيقات كل مرّة تستدعي ?valid أو تحفظ الكائن. لكن من الممكن أيضًا التحكم في وقت عمل هذه التحقيقات بإعطاء خيار on: إلى وسيلة validate إما بـ create: أو update: class Invoice < ApplicationRecord validate :active_customer, on: :create def active_customer errors.add(:customer_id, "is not active") unless customer.active? end end 7 التعامل مع أخطاء التحقيق Working with Validation Errors بالإضافة إلى وسائل ?valid و ?invalid التي تم شرحها مُسبقًا ، يدعم Rails عددًا من الوسائل للتعامل مع مجموعة الأخطاء و يحقق في صحّة الكائن. 7.1 الأخطاء Errors ترجع فئة ActiveModel::Errors يحتوي على كل الأخطاء. كل مفتاح هو اسم الخاصّية و القيمة في مجموعة مصفوفة من المتسلسلات النصّية بالأخطاء. class Person < ApplicationRecord validates :name, presence: true, length: { minimum: 3 } end person = Person.new person.valid? # => false person.errors.messages # => {:name=>["can't be blank", "is too short (minimum is 3 characters)"]} person = Person.new(name: "John Doe") person.valid? # => true person.errors.messages # => {} 7.2 الأخطاء [ ] Errors تستخدم errors عندما تريد أن تفحص رسالة الخطأ لخاصّية معيّنة. تقوم بالرد بمجموعة مصفوفة من المتسلسلات النصّية بكل رسائل الأخطاء لخاصّية مُعيّنة ، كل متسلسلة برسالة خطأ واحدة. لو لم يكن هناك أخطاء مرتبطة بالخاصّية ، تقوم بالرد بمصفوفة فارغة. class Person < ApplicationRecord validates :name, presence: true, length: { minimum: 3 } end person = Person.new(name: "John Doe") person.valid? # => true person.errors[:name] # => [] person = Person.new(name: "JD") person.valid? # => false person.errors[:name] # => ["is too short (minimum is 3 characters)"] person = Person.new person.valid? # => false person.errors[:name] # => ["can't be blank", "is too short (minimum is 3 characters)"] 7.3 إضافة الأخطاء errors.add تجعلك وسيلة add أن تضيف رسالة خطأ مرتبطة بخاصّية مُعيّنة. تقوم بأخذ الخاصّية و رسالة الخطأ كتعابير. ترد وسيلة errors.full_messages (أو مكافئاتها errors.to_a ) برسالة الخطأ بشكل مفضّل للمستخدم ، و اسم الخاصّية مكبّرًا ومضافًا على بداية كل رسالة ، كما يظهر في الأمثلة بالأسفل. class Person < ApplicationRecord def a_method_used_for_validation_purposes errors.add(:name, "cannot contain the characters !@#%*()_-+=") end end person = Person.create(name: "!@#") person.errors[:name] # => ["cannot contain the characters !@#%*()_-+="] person.errors.full_messages # => ["Name cannot contain the characters !@#%*()_-+="] أن ترفق رسالة في بداية مصفوفة errors.messages لخاصّية ما ، مكافىء لأن تستخدم errors#add . class Person < ApplicationRecord def a_method_used_for_validation_purposes errors.messages[:name] << "cannot contain the characters !@#%*()_-+=" end end person = Person.create(name: "!@#") person.errors[:name] # => ["cannot contain the characters !@#%*()_-+="] person.errors.to_a # => ["Name cannot contain the characters !@#%*()_-+="] 7.4 تفاصيل الأخطاء errors.details يمكنك تحديد نوع محقّق جدول تقطيع تفاصيل الخطأ المُعاد التقطيع باستخدام وسيلة errors.add. class Person < ApplicationRecord def a_method_used_for_validation_purposes errors.add(:name, :invalid_characters) end end person = Person.create(name: "!@#") person.errors.details[:name] # => [{error: :invalid_characters}] لكي تحسّن تفاصيل الأخطاء ، لتحتوي مجموعة الحروف غير المسموح بها على سبيل المثال ، يمكنك تمرير مفاتيح إضافيّة إلى errors.add. class Person < ApplicationRecord def a_method_used_for_validation_purposes errors.add(:name, :invalid_characters, not_allowed: "!@#%*()_-+=") end end person = Person.create(name: "!@#") person.errors.details[:name] # => [{error: :invalid_characters, not_allowed: "!@#%*()_-+="}] كل محقّقات Rails المدمجة تزيد جدول تقطيع التفاصيل بنوع محقّق متناظر. 7.5 قاعدة الأخطاء[ errors [ :base يمكنك إضافة رسائلك أخطاء مرتبطة بحالة الكائن ككل بدلًا من كونها مرتبطة بخاصّية مُعيّنة. يمكنك أيضًا استخدام تلك الوسيلة عندما تريد أن تقول أن الكائن غير صالح للاستخدام ، بغض النظر عن قيم خصائصه. بما أن [errors[ :base مصفوفة ، يمكنك ببساطة إضافة متسلسلة نصّية إليها و سوف تُستَخدَم كَرسالة خطأ. class Person < ApplicationRecord def a_method_used_for_validation_purposes errors[:base] << "This person is invalid because ..." end end 7.6 محو الأخطاء errors.clear تُستخدم وسيلة clear عندما تريد أن تمسح كل رسائل الخطأ في مجموعة الأخطاء errorscollection . بالطبع مناداة errors.clear لكائن غير صالح لن يجعله ساريًا أو صالحًا للاستخدام. مجموعة الأخطاء سوف تُفرّغ ، لكن المرة القادمة التي تستدعي فيها ?valid أو أي وسيلة تحاول أن تحفظ الكائن في قاعدة البيّانات ، سوف تعمل التحقيقات مجّددًا. لو فشل أيّ من التحقيقات سوف تُملأ مجموعة الأخطاء مجددًا. class Person < ApplicationRecord validates :name, presence: true, length: { minimum: 3 } end person = Person.new person.valid? # => false person.errors[:name] # => ["can't be blank", "is too short (minimum is 3 characters)"] person.errors.clear person.errors.empty? # => true person.save # => false person.errors[:name] # => ["can't be blank", "is too short (minimum is 3 characters)"] 7.7 حجم الأخطاء errors.size ترد وسيلة size بالعدد الكلي لرسائل الأخطاء للكائن. class Person < ApplicationRecord validates :name, presence: true, length: { minimum: 3 } end person = Person.new person.valid? # => false person.errors.size # => 2 person = Person.new(name: "Andrea", email: "andrea@example.com") person.valid? # => true person.errors.size # => 0 8 تقديم أخطاء التحقيق للعرض Displaying Validation Errors in Views بمجرّد إنشائك نموذجًا و إضافة تحقيقات ، لو كان النموذج مصنوع بواسطة شكل المواقع ، من المحتمل أن تريد عرض رسالة عند فشَل أحد التحقيقات. لأن كل تطبيق يعالج هذا النوع من الأشياء بطريقة مختلفة ، لا يتضمّن Rails أي view helpers لتساعدك على توليد تلك الرسائل بصورة مباشرة. مع ذلك ، بسبب فرط الوسائل التي يعطيك إيّاها Rails لكي تتعامل مع التحقيقات بشكل عام، تكون العملية سهلة جدّا لإنشاء ما يخصّك منها. بالاضافة إلى ذلك ، عند إنتاج هيكل رئيسي مساعد ، سوف يضع Rails بعض ERB إلى _form.html.erb الذي تنتجه والذي يعرض قائمة بكل الأخطاء في النموذج. بافتراض أن لدينا نموذج تم حفظه في متغيّر باسم article@ ، سيبدو كالتالي: <% if @article.errors.any? %> <div id="error_explanation"> <h2><%= pluralize(@article.errors.count, "error") %> prohibited this article from being saved:</h2> <ul> <% @article.errors.full_messages.each do |msg| %> <li><%= msg %></li> <% end %> </ul> </div> <% end %> علاوةً على ذلك، إذا استخدمت تصميم Rails من المساعدين لتولّد تصميماتك(نماذجك)، عندما يحدث خطأ تحقيق في الحقل سوف تنتج <div> إضافي بالقرب من المدخل. <div class="field_with_errors"> <input id="article_title" name="article[title]" size="30" type="text" value=""> </div>` يمكنك حين ذاك تشكيل ال div كما تريد. الهيكل الافتراضى الذي ينتجه Rails على سبيل المثال يضيف قاعدة ال CSS هذِهِ. .field_with_errors { padding: 2px; background-color: red; display: table; } هذا يعني أنّ أي حقل به خطأ ينتهي به الحال بإطار أحمر بعرض 2 بكسل. المصدر: توثيقات Ruby on Rails.

هل أنت من محاربي PHP القدامى وتريد معرفة ما الذي استجد منذ عدِّة سنوات؟ أم أنت منتقلٌ حديثًا إلى PHP من لغةٍ أخرى وتود معرفة الأمور المثيرة في PHP، ها قد وصلت إلى المكان الصحيح. لننفض الغبار عن معلوماتك، وتهيّأ أن تتعلم ميزاتٍ أضيفت حديثًا إلى PHP. معايير PHP-FIG أعداد مشاريع ومكتبات وأطر عمل PHP الموجودة حاليًا مهولة، إذ هنالك العديد من أطر عمل PHP المتوفرة للاستعمال، لكن من الصعب استعمالها معًا، فماذا لو استطاع أحد أطر العمل الاستفادة من مكتبة ما خارجية، بدلًا من كتابتها يدويًا، أو الاستفادة من مكتبة من إطار Laravel مثلًا؟ لهذا الغرض أُنشِئت PHP-FIG (اختصار للعبارة Framework Interoperability Group) في مؤتمر php|tek في 2009ـ التي وضعت عدِّة معايير يُرمَز لها بالاختصار PSR (أي PHP Standards Recommendations) سنورد ذكرها هنا باختصار. PSR-1: معيار كتابة الشيفرات يوضح هذا المعيار الأمور الأساسية التي يجب أخذها بعين الاعتبار عند كتابة الشيفرات لتحقيق أكبر قدر من المحمولية وإمكانية التشغيل مع بقية المكتبات والبرمجيات. يجب استعمال وسوم ‎<?php ?>‎ الاعتيادية، ووسم echo المختصر ‎<?= ?>‎ فقط. يجب أن يكون ترميز ملفات الشيفرات UTF-8 دون BOM. يجب على الملف أن يُنشِئ بنى برمجية جديدة مثل الأصناف (classes) والدوال …إلخ. دون أن يُحدِث أي "تأثير جانبي"، أو يجب أن ينفِّذ الخطوات المنطقية التي تؤدي إلى "تأثيرات جانبية" ولكن لا يُسمَح أن يقوم بكلا الأمرين. نستطيع تعريف "التأثيرات الجانبية" بالأمور غير المتعلقة بتعريف الأصناف أو الدوال، وهي تشمل: توليد المخرجات، أو تضمين الملفات (عبر include أو require)، أو الاتصال إلى الخدمات الخارجية، أو تعديل ضبط ini، أو تعديل المتغيرات العامة أو الكتابة إلى ملفات، وهلم جرًا. يجب أن تكون مجالات الأسماء (namespaces) وأسماء الأصناف متوافقة مع معيار PSR-4 (سنأتي على ذكره بعد قليل)، وهذا يعني أن كل ملف سيحتوي على صنف وحيد باسمه، وفي مجال أسماء من مرحلة (level) واحدة على الأقل. يجب أن تكون أسماء الأصناف على الشكل StudlyCaps (أي الحرف الأول من كل كلمة كبير). يجب أن تكون الثوابت المُعرَّفة في الأصناف بأحرف كبيرة وتفصل الشرطة السفلية بين الكلمات. يجب أن تكون أسماء الدوال على الشكل camelCase (أي الحرف الأول من كل كلمة كبير، عدا أول كلمة). PSR-2: معيار تنسيق الشيفرات يساعد هذا المعيار في تسهيل التعامل مع الملفات التي كتبها مبرمجون آخرون عبر تحديد قواعد مشتركة لكيفية تنسيق شيفرات PHP. يعتمد هذا المعيار على المعيار PSR-1، أي على المبرمج تطبيق قواعد PSR-1 أولًا. يجب أن تُستعمل أربعة فراغات (مسافات) لمحاذاة الشيفرات، وليست مسافات الجدولة (tabs)، ولا يجوز أن تدمج بين الطريقتين، وذلك لتفادي حدوث مشاكل في ملفات الفروقات (diff) وغيرها. ليس هنالك حدٌ أقصى لعدد المحارف في السطر، لكن يستحسن أن يكون بطول 80 محرف أو أقل، ويمكن إضافة أسطر فارغة لتحسين مقروئية النص. ولا يجوز وضع أكثر من تعبير برمجي في السطر الواحد. يجب أن تكون الكلمات المفتاحية (keywords) في PHP بأحرفٍ صغيرة، وكذلك الأمر للثوابت true و false و null. يجب وجود سطر فارغ وحيد بعد تعريف مجال الأسماء (namespace)، وكذلك الأمر بعد use. يجب أن يكون قوس البداية لصنف أو دالة في سطرٍ منفصل، وكذلك قوس النهاية؛ ولا يجوز وضع فراغ بين اسم الدالة وقوس المعاملات، ويجب وضع فراغ وحيد بعد الفاصلة "," في حال وجود أكثر من معامل. يجب تعيين مُحدِّد وصول مثل public أو private أو protected، وعدم استخدام var. يجب وضع فراغ وحيد بعد الكلمة المحجوزة لبنى التحكم (مثل if و for وغيرهما). PSR-3: معيار السجلات يُعرِّف هذا المعيار واجهةً (interface) للتسجيل (logging). PSR-4: معيار التحميل التلقائي شرحنا التحميل التلقائي في درس توزيع شيفرات PHP على عدة ملفات، يمكنك العودة إليه لمزيدٍ من المعلومات. الحزم البرمجية تخيل معي الوضع التالي: أنت مُطور PHP، لديك مشروع تود تطويره، قد تختار إطار عمل مُعين لهذه المهمة، لكنك ستحتاج إلى بضعة مكتبات إضافية للقيام بذلك، تخيل بأنك تود أن يقوم تطبيقك بنشر تحديثات مُعينة على حساب المُستخدم على تويتر، وجدت المكتبة التي ترغب في استخدامها لكنها مكتبة تعتمد على مكتبة أخرى. مُطور PHP من العصر الحجري سيقوم بالتالي: سيقوم بتحميل نُسخة من إطار العمل، ومن ثم يقوم بإنشاء مُجلد يضع فيه المكتبات الإضافية التي يحتاجها ومن ثم يُحاول فهم آلية عملها ليربطها ببعضها البعض. قد تؤتي هذه الطريقة أكلها، وقد تسمح لك بتطوير مشروعك "من دون أية مشاكل"، لكن ماذا يحدث مثلا لو تم إطلاق تحديث لأي من المكتبات التي تعتمد عليها؟ هل ستقوم بإعادة تحميلها من جديد واستبدال الإصدار القديم بالجديد؟ هل يُمكن أن تفعل ذلك لو كنت تستخدم أكثر من مكتبة يعتمد بعضها على بعض؟ لست متأكدا من ذلك. لكن ما هو البديل؟ هل عرفت فائدة أدوات إدارة الحزم؟ ما رأيك أن تكمل قراءة مقال ما هو Composer ولماذا يجب على كل مطور PHP استخدامه وتتعرف على composer وتتعلم طريقة استخدامه. كلمات المرور توجد قابلية تسجيل مستخدمين جدد في أغلبية المواقع، وهذا يعني أنَّ على المستخدم توفير كلمة مرور لكي يدخل على حسابه، لكن هل تساءلت من قبل عن أكثر الطرق أمانًا في تخزين كلمات مرور المستخدمين؟ سأنصحك بعض النصائح في هذا الصدد. لا يجدر بك معرفة كلمات مرور مستخدميك هذا يعني أنَّك ستخزِّن كلمة المرور على شكل نص بسيط في مكانٍ ما في قاعدة بياناتك، افترض مثلًا أنَّ موقعك قد تعرض للاختراق، واستطاع المُخترَق الوصول إلى قاعدة بيانات موقعك واستطاع رؤية جميع كلمات مرور مستخدميك! أنت تعرض سلامة حسابات مستخدميك الأخرى (وسمعة موقعك) للخطر. لا ترسل كلمات المرور الجديدة عبر البريد الإلكتروني هذا خطأٌ كبيرٌ لأنه يعني أنَّ الموقع يعلم كلمة مرور المستخدم، ولقد أرسلها عبر خدمة البريد (قد لا يكون الاتصال مشفرًا!)؛ وإنما عليك إرسال رابط سيسمح للمستخدم بكتابة كلمة مرور جديدة. لا تشفر (encrypt) كلمات المرور قد تظن أنَّ التشفير فكرةٌ جيدةٌ لكن تذكر أنَّ العملية قابلة للعكس، فأي شخص يملك وصولًا إلى شيفرات موقعك البرمجية سيقدر على تحويل كلمات المرور المُشفَّرة إلى أصلها. لا تستخدم MD5 من الجيد أن تستعمل طريقة تحويل غير قابلة للعكس، فهذه الطرق -مثل MD5- غير قابلة للعكس، مما يُصعِّب مهمة معرفة كلمة المرور الأصلية؛ وإذا أردت التأكد أنَّ كلمة المرور التي أدخلها المستخدم مطابقة لكلمة المرور المخزنة في قاعدة البيانات، فعليك أولًا تحويل كلمة المرور التي أدخلها بإحدى الطرق ثم مقارنتها مع الكلمة المخزنة في قاعدة البيانات. لكن يَسهُل كثيرًا توليد جداول بالقيم الأصلية والقيم المحوَّلة تسمى "جداول rainbow"، وسيتم البحث عن القيم المحولة إلى أن يُعثَر على تطابق (ينطبق المثل على SHA-1). أتت PHP 5.5 بدوال بسيطة لتحويل كلمات المرور بأمان وهي password_hash()‎ و password_verify()‎. تُستعمل الدالة الأولى لتحويل كلمة المرور إلى عبارة غير قابلة للعكس التي تستطيع تخزينها بأمان في قاعدة بياناتك. $hash = password_hash($password, PASSWORD_DEFAULT); هذا كل ما في الأمر: أول وسيط هو كلمة المرور التي تريد تحويلها، والوسيط الثاني هو الخوارزمية التي تريد استخدامها للتحويل. الخوارزمية الافتراضية هي bcrypt، ويجب أن تُخزِّن القيم الناتجة في حقل أكبر من 60 محرف في قاعدة البيانات (ربما تستعمل 255). يمكنك أيضًا تمرير PASSWORD_BCRYPT كوسيط في حال أردت أن يكون الناتج بطول 60 محرف دومًا. أما دالة password_verify()‎ فهي تقارن كلمة المرور التي أدخلها المستخدم (الوسيط الأول) بكلمة المرور المحوَّلة والمخزنة في قاعدة البيانات (الوسيط الثاني). <?php if (password_verify($password, $hash)) { // كلمة المرور صحيحة } else { // كلمة المرور غير مطابقة } الأخطاء في PHP أكثر ما يواجهه المبرمج في حياته هو الأخطاء! نحاول -نحن معشر المبرمجين- أن نتلافى حدوث الأخطاء، لكن ذلك ليس ممكنًا في الحياة العملية. علينا أن نعي أنَّ هنالك تصنيفين: الأول هو الأخطاء (errors) التي رأيتها سابقًا خلال هذه السلسلة، التي تُظهِرها الدوال المُضمَّنة في اللغة؛ والثاني هو الاستثناءات (exceptions) التي تظهر في البرامج التي تعتمد على البرمجة غرضية التوجه. تُصنَّف PHP على أنها لا تعتمد كثيرًا على الاستثناءات، وإنما تعتمد على الأخطاء. فلو حاولت مثلًا أن تطبع قيمة متغير غير معرف، فستظهر تنبيهًا لكن PHP ستكمل تفسير السكربت: $ php -a php > echo $foo; Notice: Undefined variable: foo in php shell code on line 1 أما في اللغات الأخرى التي تعتمد اعتمادًا كاملًا على الاستثناء -مثل بايثون- فستختلف النتيجة: $ python print foo Traceback (most recent call last): File “”, line 1, in NameError: name ‘foo’ is not defined التبليغ عن الأخطاء في PHP هنالك مستويات مختلفة من التبليغ عن الأخطاء في PHP، أشهر ثلاثة مستويات هي الأخطاء (errors) والتنبيهات (notices) والتحذيرات (warning). الأخطاء (errors) هي المشاكل التي تظهر في وقت التشغيل (run-time) التي يكون سببها مشاكل في الشيفرة وستسبب توقف التنفيذ. أما التنبيهات فهي رسائل إرشادية التي قد تسبب مشاكل أثناء تنفيذ السكربت، لكن التنفيذ لن يتوقف. أما التحذيرات فهي شبيهة بالأخطاء لكنها لن توقف عمل السكربت. تستطيع تغيير السلوك الافتراضي للتبليغ عن الأخطاء عبر الدالة error_reporting()‎ التي تستطيع تستطيع ضبط مستوى التبليغ عن الأخطاء أثناء التنفيذ بتمرير ثابت من الثوابت المُعرَّفة مسبقًا لمستويات الأخطاء (E_ERRORللأخطاء، E_NOTICE للتنبيهات، E_WARNING للتحذيرات). فلو كنت تريد مشاهدة الأخطاء والتحذيرات لكنك لا تريد التنبيهات، فيمكنك ضبط ذلك كالآتي: <?php error_reporting(E_ERROR | E_WARNING); تستطيع أن تخبر PHP أن تتجاهل الأخطاء في عبارة برمجية معيّنة باستخدام معامل التحكم بالأخطاء @. يمكنك وضع هذا المعامل قبل تعبير برمجي، وسيتم تجاهل أيّة أخطاء يُسبِّبها هذا التعبير. <?php echo @$foo['bar']; المثال السابق سيطبع قيمة ‎$foo['bar']‎ إن كانت موجودةً، لكنه لن يطبع شيئًا إن لم يكن المتغير ‎$foo أو المفتاح 'bar' موجودًا؛ فدون وجود معامل التحكم بالأخطاء، كان سيظهر أحد التنبيهين: PHP Notice: Undefined variable: foo أو PHP Notice: Undefined index: bar. بالطبع يمكنك استخدام العبارة الآتية لتنجب وضع معامل تجاهل الأخطاء: <?php echo isset($foo['bar']) ? $foo['bar'] : ''; الاستثناءات تمثِّل الاستثناءات جزءًا مهمًا من العديد من لغات البرمجة مثل ruby أو java، فأي شيء يحدث بشكل خاطئ في تلك اللغات -مثل فشل طلبية HTTP أو فشل الاتصال بقاعدة البيانات- فسيُرمَى (throw) استثناء يعني أنَّ هنالك خطأٌ ما. لكن PHP نفسها متساهلة جدًا بهذا الأمر، فلو فشل استدعاء الدالة file_get_contents()‎ فستحصل على FALSE وربما رسالة تحذيرية (أي من المستوى E_WARNING)؛ أما أطر العمل الحديثة، فتستعمل الاستثناءات. تبنى آلية معالجة الأخطاء في PHP على وضع التعبيرات البرمجية في كتلة try التي تريد مراقبتها من أجل الأخطاء، فلو حدث استثناءٌ ما داخل كتلة try (تحدث الاستثناءات عند "رميها" [throw]) فسيُلتَقَط باستخدام catch التي تلي كتلة try التي رمت الاستثناء. أنا متأكدٌ أنَّك تتساءل عن معنى ما سبق. ما رأيك أن نأخذ مثالًا توضيحيًا يساعد على الفهم: <?php try { $num = 10; if ($num < 20) { throw new Exception("Exception here!"); } $foo = "bar"; } catch(Exception $exception) { print "Exception!\n"; } ?> دخل مُفسِّر PHP إلى كتلة try وبدأ تنفيذ الشيفرة، وعند وصوله إلى السطر throw new Exception توقف عن تنفيذ كتلة try وانتقل إلى كتلة catch؛ لاحظ أنَّه عندما "يغادر" مُفسِّر PHP كتلة try فلن يعود إليها مطلقًا، أي أنَّ السطر ‎$foo = "bar"‎ لن يُنفَّذ. قد ترى أنَّ كتلة catch معقدة في بادئ الأمر، لكنني سأريك مثلًا يعتمد على أنَّ مفسر PHP سينتقل إلى كتلة catch المناسبة، لكن علي أولًا شرح التعبير (catch(Exception $exception. نُحدِّد في كتلة catch أنَّ الصنف هو Exception لأنَّ على PHP أن تُحدِّد أي كتلة من كتل catch يجب تنفيذها بالبحث عن الصنف الموافق للصنف الذي رُميَ. أو بالأحرى، تُجري PHP عملية instanceof (هل تذكرها من درس البرمجة كائنية التوجه؟) وهذا يعني أنَّ على الاستثناء الذي رُميَ أن يكون من الصنف المُحدَّد أو من صنف مشتق منه (أعلم تمامًا العلم أنَّ ما سبق يبدو معقدًا، لكنه أبسط بكثير مما تظن). لاحظ أنَّ جميع الاستثناءات مشتقة من الصنف Exception الذي يوفِّر وظائف أساسية، وأغلبية الدوال الموجودة في الصنف Exception هي final أي لا يمكن إعادة كتابتها في الأصناف المشتقة. يمكنك مثلًا استدعاء الدالة ‎$exception->getMessage()‎ لمعرفة رسالة الخطأ ("Exception here!‎" في المثال السابق)، أو يمكنك استدعاء getFile()‎ لمعرفة الملف الذي رمى الاستثناء. هذا المثال يوضِّح الشرح السابق: <?php class ExceptFoo extends Exception { } class ExceptBar extends ExceptFoo { } try { $foo = "bar"; throw new ExceptFoo("Baaaaad PHP!"); $bar = "baz"; } catch (ExceptFoo $exception) { echo "Caught ExceptFoo\n"; echo "Message: {$exception->getMessage()}\n"; } catch (ExceptBar $exception) { echo "Caught ExceptBar\n"; echo "Message: {$exception->getMessage()}\n"; } catch (Exception $exception) { echo "Caught Exception\n"; echo "Message: {$exception->getMessage()}\n"; } ?> ناتج السكربت السابق: Caught ExceptFoo Message: Baaaaad PHP! هذا منطقي لأننا رمينا استثناء من الصنف ExceptionFoo، ولهذا ستنتقل PHP إلى كتلة catch. جرب الآن هذه الشيفرة: <?php class ExceptFoo extends Exception { } class ExceptBar extends ExceptFoo { } try { $foo = "bar"; throw new ExceptBar("Baaaaad PHP!"); $bar = "baz"; } catch (ExceptFoo $exception) { echo "Caught ExceptFoo\n"; echo "Message: {$exception->getMessage()}\n"; } catch (ExceptBar $exception) { echo "Caught ExceptBar\n"; echo "Message: {$exception->getMessage()}\n"; } catch (Exception $exception) { echo "Caught Exception\n"; echo "Message: {$exception->getMessage()}\n"; } ?> لماذا ناتج الشيفرة السابقة مماثلة لما قبلها؟ لأنَّ PHP تنتقل إلى أول كتلة catch مُطابِقة لصنف الاستثناء أو أيّة أصناف أب له؛ ولما كان ExceptionBar مشتقٌ من ExceptionFoo، وكانت كتلة catch التابع للصنف ExceptionFoo تأتي قبل ExceptionBar، فستنفَّذ كتلة ExceptionFoo. يمكنك إعادة كتابة الشيفرة كالآتي لتفادي هذه الإشكالية: <?php class ExceptFoo extends Exception { } class ExceptBar extends ExceptFoo { } try { $foo = "bar"; throw new ExceptBar("Baaaaad PHP!"); $bar = "baz"; } catch (ExceptBar $exception) { echo "Caught ExceptBar\n"; echo "Message: {$exception->getMessage()}\n"; } catch (ExceptFoo $exception) { echo "Caught ExceptFoo\n"; echo "Message: {$exception->getMessage()}\n"; } catch (Exception $exception) { echo "Caught Exception\n"; echo "Message: {$exception->getMessage()}\n"; } ?> بقي أمرٌ بسيطٌ تجدر الإشارة إليه ألا وهو كتلة finally الموجودة في إصدار PHP 5.5 وما بعده، التي تضمن لك تنفيذ الشيفرات البرمجية الموجودة فيها دائمًا حتى لو حدث استثناءٌ ما. <?php try { complicatedCode(); } catch (NastyException $e) { handleError($e); } finally { importantCleanup(); } ?> المولدات Generators هذه ميزةٌ جديدةٌ في PHP منذ الإصدار 5.5، وهي تسمح لك باستعمال حلقة foreach للمرور على مجموعة من البيانات دون الحاجة إلى إنشاء مصفوفة في الذاكرة، الأمر الذي قد يؤدي إلى تجاوز حد استهلاك الذاكرة المسموح، أو إلى وقت معالجة كبير… إذ تستطيع كتابة دالة مولدة (generator function) التي تشبه الدوال العادية، إلا أنها بدلًا من إعادة قيمة ما، فهي "تُنتِج" (yield) قيمًا لكي يتم المرور عليها باستعمال الحلقات. مثالٌ بسيطٌ عنها هو دالة range(0, 1000000)‎ التي تولد مصفوفة فيها قيم عددية من الصفر إلى المليون، وستستهلك 100 ميغابايت من الذاكرة العشوائية. ونستطيع بدلًا من ذلك أن نكتب مولدة اسمها xrange()‎ -على سبيل المثال- وستستهلك أقل من 1 كيلوبايت! <?php function xrange($start, $limit) { for ($i = $start; $i <= $limit; $i++) { // استعملنا yield بدلًا من return yield $i; } } // استعملنا المصفوفة المُعادة من استدعاء الدالة range في foreach كالمعتاد foreach (range(1, 9) as $number) { echo "$number "; } echo "\n"; // وكذلك استعملنا نواتج المولدة xrange foreach (xrange(1, 9) as $number) { echo "$number "; } ?> الفرق بين الطريقتين في استهلاك الذاكرة فقط، ولا تأثير لها على سرعة التنفيذ. المصادر راجع صفحة Basic Coding Standard و Coding Style Guide و Logger Interface و Autoloading Standard، وتابع الجديد عبر موقع PHP-FIG. راجع مقالة ما هو Composer ولماذا يجب على كل مطور PHP استخدامه لصاحبها يوغرطة بن علي. لمزيد من المعلومات حول تحويل كلمات المرور، راجع صفحة password_hash و password_verify في دليل PHP، وهذا السؤال على stack overflow. انظر إلى قسم الاستثناءات في PHP: The Right Way، ومقالة Exception handling، وصفحة Exceptions في دليل PHP. تعلم المزيد عن المولدات عبر دليل PHP بصفحتيه Generators overview و Generator syntax.

يشرح هذا المقال طريقة كتابة تعليمات تحوي متغيرات تخزن فيها قيمًا مختلفة، كالأرقام والكلمات، وتحوي أيضًا عوامل حسابية (operators)، وهي رموز تمثل عمليات حسابية. ثم يُعرّج على فكرة التركيب (أي استخدام مزايا اللغة التي تعرفنا عليها سابقاً مع بعضها)، كما يتحدث عن ثلاثة أنواع من الأخطاء البرمجية ونذكر فيه المزيد من النصائح عن تنقيح البرامج من الأخطاء. التصريح عن المتغيرات أحد أقوى المزايا لأي لغة برمجة هي القدرة على تعريف ومعالجة المتغيرات (variables). المتغير هو منطقة ذات اسم تخزّن قيمة (value). قد تكون القيم أرقامًا، أو نصوصًا، أو صورًا، أو مقاطع صوتية، وغيرها من أنواع البيانات. عليك أولًا التصريح عن متغير ثم تخزين القيم فيه. String message; هذا النوع من التعليمات يدعى تصريح (declaration)، لأنها تصرح أن نوع المتغير المدعو message هو String. لكل متغير نوع (type) يحدد نوع القيم التي يمكنه تخزينها. مثلًا، النوع int يخزن الأعداد الصحيحة، والنوع String يخزن السلاسل المحرفية. بعض الأنواع تبدأ بحرف كبير وبعضها الآخر يبدأ بحرف صغير. سنعرف معنى هذا التمييز لاحقًا، لكن الآن عليك الانتباه لكتابتها بشكل صحيح. ليس هناك نوع Int ولا string. لإنشاء متغير من النوع الصحيح، التعليمة هي: int x; حيث x هو اسم كيفي اخترناه للمتغير. بشكل عام، عليك اختيار أسماء المتغيرات بحيث تدل على دور المتغير في البرنامج. مثلًا، عندما ترى التصريحات التالية عن المتغيرات: String firstName; String lastName; int hour, minute; هذا المثال يصرح عن متغيرين من نوع String ومتغيرين من نوع int. عندما يتكون اسم المتغير من كلمتين أو أكثر، مثل المتغير firstName، جرت العادة على جعل الحرف الأول من كل كلمة حرفًا كبيرًا عدا الكلمة الأولى. أسماء المتغيرات حساسة لحالة الأحرف، ولذلك فالمتغير firstName مختلف عن المتغير firstName أو FirstName. يوضح هذا المثال أيضًا صيغة التصريح عن عدة متغيرات من نفس النوع في سطر واحد: كلًا من hour و minute هو عدد صحيح (متغير من النوع int). لاحظ أن كل تعليمة تصريح تنتهي بفاصلة منقوطة. يمكنك تسمية متغيراتك كما تشاء. لكن هناك حوالي 50 كلمة محجوزة، تدعى الكلمات المفتاحية (keywords)، ولا يسمح لك باستخدامها كأسماء لمتغيراتك. هذه الكلمات تشمل public، وclass، وstatic، وvoid، وint، التي يستخدمها المترجم لتحليل بنية البرنامج. هناك قائمة كاملة بالكلمات المفتاحية موجودة، لكن لا حاجة لحفظها. معظم المحررات المستخدمة في البرمجة توفر ميزة "تلوين الشفرة" (syntax highlighting)، التي تجعل الأجزاء المختلفة من البرنامج تظهر بألوان مختلفة. الإسناد بعد أن صرحنا عن بعض المتغيرات، سنستخدمها لتخزين بعض القيم فيها. يمكننا عمل ذلك باستخدام تعليمة الإسناد (assignment). message = "Hello!"; // give message the value "Hello!" hour = 11; // assign the value 11 to hour minute = 59; // set minute to 59 يبين هذا المثال ثلاث تعليمات إسناد، والتعليقات تظهر ثلاثة أساليب يستخدمها الناس أحيانًا عندما يقرؤون تعليمات الإسناد. قد تكون المفردات مربكة هنا، لكن الفكرة واضحة : عندما تصرح عن متغير، أنت تنشئ منطقة تخزينية لها اسم. عندما تطبق تعليمة الإسناد على متغير، فأنت تغير القيمة التي يحويها. كقاعدة عامة، يجب أن يكون نوع المتغير من نفس نوع القيمة التي تسندها إليه. مثلًا، لا يمكنك تخزين سلسلة محرفية في المتغير minute أو عددًا صحيحًا في message. من ناحية أخرى، هذه القاعدة قد تكون مصدرًا للإرباك أحيانًا، بسبب وجود العديد من الطرق التي تسمح لك بتحويل القيم من نوع لآخر، وأحيانًا تحول Java الأشياء تلقائيًا. لكن الآن عليك فقط أن تتذكر القاعدة العامة بأن المتغيرات والقيم يجب أن تكون من نفس النوع، وسنتحدث عن الحالات الخاصة لاحقًا. أحد مصادر الإرباك هو أن بعض السلاسل المحرفية تبدو مثل الأرقام، لكنها ليست كذلك. مثلًا، يمكن أن يخزن المتغير message السلسلة المحرفية "123"، المكونة من المحارف '1' و '2' و '3'، لكنها ليست مثل العدد الصحيح 123. message = "123"; // legal message = 123; // not legal يجب تهيئة المتغيرات (initialize)، أي إسناد قيمة لها أول مرة، قبل أن تستخدمها. يمكنك التصريح عن متغير ثم إسناد قيمة له لاحقًا، كما في المثال السابق. كما يمكنك أيضًا التصريح عن المتغير وتهيئته بسطر واحد: String message = "Hello!"; int hour = 11; int minute = 59; مخططات الحالة قد تظن أن تعليمة a = b هي تعليمة مساواة لأن Java تستخدم الرمز = لعملية الإسناد. لكنها ليست مساواة! المساواة عملية تبديلية، أما الإسناد فلا. على سبيل المثال، في الرياضيات إذا كان a = 7 إذًا 7 = a. لكن في Java ‏a = 7;‎ تعليمة إسناد مشروعة، لكن 7 = a‎ غير مشروعة. يجب أن يكون الطرف الأيسر من تعليمة الإسناد متغيرًا (اسمًا لموقع تخزيني). في الرياضيات أيضًا، جملة المساواة صحيحة دائمًا. إذا كان a = b الآن، فإن a سيبقى مساويًا لـ b دائمًا. أما في Java، فتعليمة الإسناد قد تجعل قيمتي متغيرين متساويتان، لكن قد لا يستمران على هذه الحال. int a = 5; int b = a; // a and b are now equal a = 3; // a and b are no longer equal في السطر الثالث تغيرت قيمة a، لكن قيمة b لم تتغير، وبالتالي لم يبق المتغيران متساويان. المتغيرات في البرنامج مع قيمها الحالية تشكل حالة البرنامج (state). يُظهِر الشكل 2.1 حالة البرنامج بعد تنفيذ هذه التعليمات. تدعى هذه المخططات التي تظهر حالة البرنامج بمخططات الحالة (state diagrams). يُمثَّل كل متغير بصندوق يظهر اسم المتغير خارجه وقيمة المتغير داخله. أثناء تنفيذ البرنامج تتغير الحالة، لذلك عليك اعتبار مخططات الحالة كتمثيل لحظي لنقطة محددة في مسار التنفيذ. طباعة المتغيرات يمكنك عرض قيمة متغير باستخدام println أو print. في التعليمات التالية صرحنا عن متغير اسمه firstLine، وأسندنا له القيمة "!Hello, again"، وعرضنا تلك القيمة. String firstLine = "Hello, again!"; System.out.println(firstLine); عندما نتحدث عن عرض متغير فنحن نقصد قيمة المتغير عمومًا. أما لعرض اسمالمتغير، فعليك أن تضعه بين علامتي اقتباس. مثلًا: System.out.print("The value of firstLine is "); System.out.println(firstLine); خرج هذا البرنامج هو: The value of firstLine is Hello, again! بنية تعليمة عرض المتغير هي نفسها بغض النظر عن نوع المتغير. مثلًا: int hour = 11; int minute = 59; System.out.print("The current time is "); System.out.print(hour); System.out.print(":"); System.out.print(minute); System.out.println("."); خرج هذا البرنامج هو: The current time is 11:59. لوضع عدة قيم على نفس السطر، من الشائع استخدام عدة تعليمات print ثم تتبعها تعليمة println في النهاية. لكن لا تنسَ تعليمة println على العديد من الحواسيب، يتم تخزين خرج تعليمات print دون عرضه على الشاشة حتى استدعاء println؛ وعندها يظهر السطر كله دفعة واحدة. إذا أغفلت تعليمة println، فقد يعرض البرنامج الخرج المخزن في أوقات غير متوقعة أو ربما انتهى البرنامج دون طباعة أي شيء. العوامل الحسابية العوامل (operators) هي رموز تمثل حسابات بسيطة. مثلًا، عامل الجمع هو +، وعامل لطرح -، والضرب *، والقسمة /. يحول البرنامج التالي الوقت إلى دقائق: int hour = 11; int minute = 59; System.out.print("Number of minutes since midnight: "); System.out.println(hour * 60 + minute); في هذا المثال، لدينا التعبير (expression) التالي: hour * 60 + minute، الذي يمثل قيمة وحيدة بعد الحساب. عند تنفيذ البرنامج، يستبدل كل متغير بقيمته الحالية، ثم تطبق العوامل عليها. تدعى القيم التي تعمل العوامل عليها بالمعاملات (operands). نتيجة المثال السابق هي: Number of minutes since midnight: 719 التعابير هي تراكيب تتألف بشكل عام من أرقام، ومتغيرات، وعوامل. عند ترجمة وتنفيذ التعابير ستنتج لدينا قيمة وحيدة. مثلًا، التعبير 1 + 1 قيمته 2. وفي التعبير hour - 1 تستبدل Java المتغير بقيمته، وبذلك ينتج ‎11 - 1، الذي قيمته 1. أما في التعبير hour * 60 + minute فيستبدل المتغيران بقيمتيهما، وهذا يعطي ‎11 * 60 + 59. تنفذ عملية الضرب أولًا، معطية التعبير ‎660 + 59. بعد ذلك تجرى عملية الجمع التي تنتج 719. عمليات الجمع والطرح والضرب كلها تعمل كما تتوقع منها تمامًا، لكن عملية القسمة قد تفاجئك. مثلًا، نحاول في التعليمتين التاليتين حساب الجزء الذي مضى من الساعة: System.out.print("Fraction of the hour that has passed: "); System.out.println(minute / 60); الخرج هو: Fraction of the hour that has passed: 0 هذه النتيجة تحير الناس عادة. قيمة minute هي 59، وناتج قسمة 59 على 60 هو 0.98333، وليس 0. المشكلة هي أن Java تنفذ عملية "القسمة الصحيحة" عندما يكون المعاملين عددين صحيحين. عملية القسمة الصحيحة تقرب الناتج دومًا إلى العدد الصحيح السابق، حتى في الحالات التي يكون العدد الصحيح التالي أقرب مثل حالتنا هذه. يمكننا كحل بديل حساب النسبة المئوية بدلًا من العدد العشري: System.out.print("Percent of the hour that has passed: "); System.out.println(minute * 100 / 60); الخرج الجديد هو: Percent of the hour that has passed: 98 لقد قربت النتيجة للأسفل هنا أيضًا، لكن النتيجة الآن صحيحة تقريبًا على الأقل. النقطة العائمة هناك حل مناسب أكثر وهو استخدام أعداد النقطة العائمة (floating-point)، التي تمثل الأعداد العشرية كما تمثل الأعداد الصحيحة أيضًا. في Java، يستخدم النوع double (اختصارًا لعبارة double-precision) افتراضيًا لأعداد النقطة العائمة. يمكنك إنشاء المتغيرات من نوع double وإسناد القيم لها باستخدام نفس الصيغ التي استخدمناها للأنواع الأخرى: double pi; pi = 3.14159; تنفذ Java عملية "قسمة النقطة العائمة" (floating-point division) إذا كان أحد المعاملات أو كلاهما من النوع double. وهكذا يمكننا حل المشكلة التي واجهتنا في القسم السابق: double minute = 59.0; System.out.print("Fraction of the hour that has passed: "); System.out.println(minute / 60.0); الخرج هو: Fraction of the hour that has passed: 0.9833333333333333 ورغم فائدة أعداد النقطة العائمة، إلا أنها قد تسبب الإرباك. مثلًا، Java تفرّق بين القيمة الصحيحة 1 وبين القيمة العشرية 1.0، حتى لو بدا أنهما نفس العدد، فهما يختلفان بالنوع، وعلى وجه الدقة، لا يسمح لك بتنفيذ عمليات إسناد بين النوعين. مثلًا، ما يلي ليس مسموحًا لأن المتغير على الطرف الأيسر من النوع int أما القيمة المسندة له على الطرف الأيمن هي double: int x = 1.1; // compiler error من السهل نسيان هذه القاعدة لأن هناك حالات عديدة تحول فيها Java أحد الأنواع إلى النوع الآخر تلقائيًا. مثلًا: double y = 1; // legal, but bad style من المفترض ألا تكون التعليمة السابقة مشروعة، لكن Java تسمح بها عن طريق التحويل القيمة الصحيحة 1 إلى القيمة العشرية 1.0 تلقائيًا. هذا التساهل مريح، لكنه يسبب المشاكل للمبتدئين غالبًا. مثلًا: double y = 1 / 3; // common mistake قد تتوقع أن يعطى المتغير y القيمة 0.333333، وهي قيمة عشرية مشروعة، لكنه في الواقع سيعطى القيمة 0.0. السبب هو أن العبارة على اليمين هي نسبة بين عددين صحيحين، لذلك تجري Java عملية قسمة صحيحة، والتي تنتج القيمة الصحيحة 0. ثم يتم تحويلها إلى قيمة عشرية، الناتج هو 0.0. إحدى الطرق لحل هذه المشكلة (بعد أن تكتشف أن هذه هي المشكلة) هو جعل الطرف الأيمن عبارة عشرية. التعليمة التالية ستعطي y القيمة 0.333333، كما هو متوقع. double y = 1.0 / 3.0; عليك دائمًا إسناد قيم عشرية لمتغيرات النقطة العائمة في كتابتك. لن يجبرك المترجم على ذلك، لكنك لا تعرف أبدًا متى تظهر لك غلطة بسيطة وتعود عليك وبالًا. أخطاء التقريب معظم أرقام النقطة العائمة صحيحة تقريبيًا. يمكن تمثيل بعض الأرقام بدقة، مثل القيم الصحيحة ذات الأحجام المعقولة. أما الكسور الدورية، مثل 1/3، أو الأرقام غير النسبية، مثل π، فلا يمكن تمثيلها بدقة. الفرق بين العدد الذي نريد والعدد الذي نحصل عليه يدعى خطأ التقريب (rounding error). مثلًا، يجب أن تكون التعليمتان التاليتان متكافئتين: System.out.println(0.1 * 10); System.out.println(0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1); لكن الخرج سيكون كما يلي على معظم الحواسيب: 1.0 0.9999999999999999 المشكلة هي أن 0.1، وهو عدد عشري منته في الأساس 10، هو كسر دوري في الأساس 2، ولذلك يكون تمثيله في النقطة العائمة تقريبي حتمًا. وعندما نجمع الأعداد التقريبية معًا تتراكم أخطاء التقريب. الحساب بالنقطة العائمة له مزايا تفوق عيوبه في العديد من التطبيقات، كالرسوميات الحاسوبية، والتشفير، والتحليل الإحصائي، وإظهار (rendering) الوسائط المتعددة. لكن إذا أردت دقة مطلقة، عليك استخدام الأعداد الصحيحة بدلًا منها. خذ على سبيل المثال حساب بنك فيه رصيد قيمته 123.45$: double balance = 123.45; // potential rounding error في هذا المثال، ستصبح الأرصدة غير دقيقة مع الوقت واستخدام المتغير في العمليات الحسابية كالسحب والإيداع. ستكون النتيجة سخط العملاء أو دعاوى قضائية. يمكنك تفادي المشكلة بتمثيل الرصيد كعدد صحيح: int balance = 12345; // total number of cents هذا الحل صحيح طالما أن عدد السنتات لا يتجاوز أكبر قيمة صحيحة يمكن تخزينها، وهي حوالي 2 مليار. العمليات على السلاسل المحرفية بشكل عام، لا يمكنك تطبيق العمليات الرياضية على السلاسل المحرفية، حتى لو كانت السلاسل المحرفية تبدو وكأنها أرقام. التعابير التالية غير مشروعة: "Hello" - 1 "World" / 123 "Hello" * "World" العامل + يعمل مع السلاسل المحرفية، لكنه قد لا ينتج ما تتوقعه. يجري عامل + عملية ربط السلاسل (concatenation) أي دمج المعاملين بوصلهما معًا. وهكذا فإن "Hello" + "World" ستعطي السلسلة "Hello World". أو إذا كان لديك متغير اسمه name من النوع String، فسوف يدمج التعبير "Hello" + "Name" قيمة name مع كلمة الترحيب. بما أن عملية الجمع معرفة للأرقام والسلاسل المحرفية أيضًا، فإن Java تجري عمليات تحويل تلقائية قد لا تتوقعها: System.out.println(1 + 2 + "Hello"); // the output is 3Hello System.out.println("Hello" + 1 + 2); // the output is Hello12 تنفذ Java هذه العمليات من اليسار إلى اليمين. في السطر الأول، 1 + 2 يساوي 3، و 3 + "Hello" يساوي "3Hello". أما في السطر الثاني، Hello" + 1" يساوي "Hello1"، و Hello1" + 2" يعطي "Hello12". ترتيب الحساب عندما يظهر أكثر من عامل في تعبير حسابي فسوف تنفذ حسب ترتيب العمليات (order of operation). بشكل عام، تنفذ Java العمليات حسب ترتيب ورودها من اليسار إلى اليمين (كما رأينا في القسم السابق). لكن Java تتبع قواعد الرياضيات في العمليات الحسابية: عمليتي الضرب والقسمة لهما ”أولوية“ (precedence) على الجمع والطرح. لذا فإن 3 * 2 + 1 سيعطي 7، وليس 9، كما أن 2 / 4 + 2 تعطي 4، وليس 3. إذا كان للعوامل نفس الأولوية فسوف تنفذ بالترتيب من اليسار إلى اليمين. ففي التعبير الحسابي minute * 100 / 60، يتم تنفيذ عملية الضرب أولًا، وإذا كانت قيمة minute هي 59 فسوف ينتج لدينا 60 / 5900، والذي بدوره يعطي 98. لو أن تنفيذ العملية الحسابية جرى من اليمين لليسار، ستكون النتيجة 1 * 59 والذي هو 59، وهو جواب خاطئ. في أي وقت ترغب فيه بتجاوز قواعد الأولوية (أو أنك لم تكن واثقًا من تلك القواعد) يمكنك استعمال الأقواس. يتم تنفيذ العمليات ضمن الأقواس أولًا، لهذا فإن 3 * (2 + 1) يعطي 9. يمكنك استعمال الأقواس أيضًا لجعل العبارات الحسابية أسهل للقراءة، كما في 60 / (minute * 100)، مع أنها لا تغير النتيجة. لا تجهد نفسك في حفظ ترتيب تنفيذ العمليات، خصوصًا مع العوامل الأخرى. إذا لم يكن ترتيب التنفيذ واضحًا عند النظر إلى التعبير، فاستخدم الأقواس لجعله واضحًا. التركيب في الأجزاء السابقة كنا نتعرف على مكونات لغة البرمجة: المتغيرات، والتعابير، والتعليمات بشكل مستقل، دون أن نناقش طريقة استخدامها معاً. أحد أهم ميزات لغات البرمجة هي قدرتها على تركيب (compose) الأجزاء الصغيرة مع بعضها. مثلاً، نحن نعرف كيف نضرب الأرقام ونعرف كيف نعرض القيم. يمكننا دمج هاتين العمليتين في تعليمة واحدة: System.out.println(17 * 3); يمكن استخدام أي تعبير حسابي داخل تعليمات الطباعة. لقد شاهدنا مثالاً على هذا من قبل: System.out.println(hour * 60 + minute); يمكنك أيضاً وضع تعابير حسابية متنوعة على الطرف الأيمن لعملية الإسناد: int percentage; percentage = (minute * 100) / 60; لكن الطرف الأيسر لا بد أن يكون اسم متغير، وليس تعبيراً. ذلك لأن الطرف الأيسر يدل على موقع تخزين النتيجة، والتعابير لا تمثل مواقع تخزينية. hour = minute + 1; // correct minute + 1 = hour; // compiler error قد لا تبهرك القدرة على تركيب العمليات الآن، لكننا سنرى لاحقاً أمثلة تسمح لنا بكتابة حسابات معقدة بشكل مرتب وأنيق. لكن لا تبالغ كثيراً، فالتعابير الكبيرة المعقدة قد تصعب قراءتها وتنقيحها من الأخطاء. أنواع الأخطاء هناك ثلاثة أنواع يحتمل أن تحدث في البرنامج: أخطاء الترجمة. أخطاء التنفيذ. الأخطاء المنطقية. من المفيد التمييز بينها في سبيل تتبعها بشكل أسرع، وقبل أن نتحدث عنها واحدة واحدة، يمكنك الاطلاع على الفيديو الآتي الذي يشرحها بالتفصيل: تحدث أخطاء الترجمة (compile-time errors) عندما تخالف التراكيب النحوية (syntax) للغة Java. مثلاً، يجب أن تكون أزواج الأقواس متناظرة. ولذلك فإن (2 + 1) صيغة مقبولة أما (8 ليست كذلك. في الحالة الثانية، لن تتمكن من ترجمة البرنامج، وسيعرض المترجم رسالة خطأ. تدل رسائل الخطأ التي يعرضها المترجم على موقع حدوث الخطأ في البرنامج عادة، وأحياناً تخبرك بطبيعة الخطأ بدقة. على سبيل المثال، لنعد إلى برنامج hello world: public class Hello { public static void main(String[] args) { // generate some simple output System.out.println("Hello, World!"); } } إذا نسيت الفاصلة المنقوطة في نهاية تعليمة الطباعة، فقد تظهر لك رسالة خطأ كما يلي: File: Hello.java [line: 5] Error: ‘;’ expected هذا جيد جداً: موقع الخطأ صحيح، ورسالة الخطأ تخبرك بالمشكلة. لكن رسائل الأخطاء ليست يسيرة الفهم دوماً. أحياناً يعطي المترجم مكان اكتشاف الخطأ في البرنامج، وليس مكان حدوثه حقاً. وأحياناً يكون وصف المشكلة محيراً أكثر مما هو مفيد. مثلاً، إذا نسيت قوس الإغلاق المعقوف في نهاية main (سطر 6)، قد تحصل على رسالة تشبة الرسالة التالية: File: Hello.java [line: 7] Error: reached end of file while parsing هناك مشكلتان هنا. أولاً، رسالة الخطأ مكتوبة من وجهة نظر المترجم، وليس وجهة نظرك أنت. عملية الإعراب (parsing) هي عملية قراءة البرنامج قبل الترجمة؛ فإذا وصل المترجم لنهاية الملف قبل انتهاء الإعراب، فهذا يدل على نقصان شيء ما. لكن المترجم لا يعرف ما هو. كما أنه لا يعرف أين. يكتشف المترجم الخطأ عند نهاية البرنامج (سطر 7)، لكن القوس الناقص يجب أن يكون على السطر السابق. تحوي رسائل الأخطاء معلومات مفيدة، لذلك عليك محاولة قراءتها وفهمها. لكن لا تأخذها بشكل حرفي تماماً. ستمضي غالباً وقتاً طويلاً خلال الأسابيع الأولى في سيرتك البرمجية وأنت تتابع أخطاء الترجمة. لكن مع زيادة خبرتك، سوف ترتكب أخطاءً أقل وستعثر عليها أسرع. النوع الثاني من الأخطاء هي أخطاء التنفيذ (run-time errors)، وقد سمّيت كذلك لأنها لا تظهر قبل تنفيذ البرنامج. في Java، تظهر هذه الأخطاء عندما ينفذ المفسر شفرة بايت ويحدث خطأ ما. تدعى هذه الأخطاء "استثناءات" (exceptions) لأنها تدل عادة على حدوث شيء استثنائي (وسيء). أخطاء التنفيذ نادرة في البرامج البسيطة التي ستراها في الفصول القليلة الأولى، لذلك قد لا ترى واحداً إلا بعد حين. عند حدوث خطأ تنفيذي، يعرض المفسر رسالة خطأ تحوي معلومات تشرح ما حدث وتحدد مكان حدوثه. مثلاً، إذا أجريت عملية قسمة على صفر عن غير قصد فسوف تظهر رسالة تشبه ما يلي: Exception in thread “main” java.lang.ArithmeticException: / by zero at Hello.main(Hello.java:5) بعض هذه المعلومات مفيد في تنقيح البرنامج من الأخطاء. يتضمن السطر الأول اسم الاستثناء java.lang.ArithmeticException ورسالة تبين ما حدث بدقة أكبر "by zero /". يظهر السطر التالي العملية التي حدث فيها الخطأ؛ حيث يقصد بعبارة Hello.main العملية main في الصنف Hello. كما أنه يذكر أيضاً اسم الملف الذي عرفت فيه العملية (Hello.java) ورقم السطر الذي حدث فيه الخطأ (5). أحياناً تحوي رسائل الأخطاء معلومات إضافية لن تفهم معناها الآن. لذلك سيكون أحد التحديات معرفة الأجزاء المفيدة دون أن تغرق بالمعلومات الإضافية. وعليك أن تنتبه أيضاً أن السطر الذي سبب انهيار تنفيذ البرنامج قد لا يكون السطر الذي يحتاج للتصحيح. النوع الثالث من الأخطاء هو الأخطاء المنطقية (logic error). إذا كان هناك خطأ منطقي في برنامجك، فستتم ترجمته وتشغيله دون تولد أي رسالة خطأ، لكنه لن يعطي الناتج الصحيح المطلوب، بل سينفذ ما طلبته منه حرفياً. مثلاً، هذا برنامج hello world فيه خطأ منطقي: public class Hello { public static void main(String[] args) { System.out.println("Hello, "); System.out.println("World!"); } } هذا البرنامج يترجم وينفذ بشكل سليم، لكن الخرج هو: Hello, World! على فرض أننا أردنا أن يكون الخرج على سطر واحد، فهذا الناتج غير صحيح. المشكلة هي أن السطر الأول يستخدم println، بينما نحن أرنا غالباً استخدام print. قد يصعب التعرف على الأخطاء المنطقية لأنك ستضطر للعمل بالمقلوب: تنظر إلى مخرجات البرنامج وتحاول استنتاج السبب الذي يجعله يعطي هذه النتائج الخاطئة، وكيف تجعله يعطي النتائج الصحيحة. عادة لا يستطيع المترجم ولا المفسر مساعدتك هنا، لأنهما لا يعرفان ما هو الشيء الصحيح المطلوب. ترجمة -وبتصرف- للفصل Variables and operators من كتاب Think Java: How to Think Like a Computer Scientist لكاتبيه Allen B. Downey و Chris Mayfield.