PDA

View Full Version : سوال در مورد cache در php



persian-boy
پنج شنبه 05 مرداد 1391, 01:25 صبح
سلام دوستان

چرا در php ما از cache استفاده میکنم . البته بهتر بگم در کوئری هامون



$r = null;
if ( $stmt = DB::$mysqli->prepare("test") ) {
if ( !$stmt->bind_param("i", $id) )
throw new Exception("Can not bind params");

if ( !$stmt->execute() )
throw new Exception("Can not execute stmt");

$stmt->bind_result('test');

if ( $stmt->fetch() )
$r = array('test');

$stmt->close();
} else
throw new Exception("Can not prepare stmt");




ساختارش به چه شکله ؟

مثلا خطوط ریر یعنی چی ؟

throw new Exception("Can not prepare stmt");

catch (Exception $x) {

try

ممنون میشم یک توضیح کامل بفرمایید

desatir7316
پنج شنبه 05 مرداد 1391, 01:40 صبح
چیز سختی نیست
شما یه کد می نویسید که مثلا اونو توی بلوک try قرار میدید
بعد اون پایین می تونید هر جند تا بلوک catch براش بنویسید که فلان خطا رو گرفت این فلان catch اجرا بشه
نهایتا می تونید یه بلوک catch کلی هم بنویسید که مثلا اگه خطای که رخ داده به هیج کدوم از catch هایی که شما پیش بینی کردید مربوط نیست توی اون catch نهایی برنامه یه عکس العملی از خودش نشون بده

مثال:

try {
$error = 'Always throw this error';
throw new Exception($error);

// Code following an exception is not executed.
echo 'Never executed';

} catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
}

// Continue execution
echo 'Hello World';
?>

colors
پنج شنبه 05 مرداد 1391, 09:43 صبح
درود

البته این روهم من اضافه کنم که شیوه رفتارش به این شکله که:

میگه سعی کن بلاک try رو اجرا کنی و اگر نتونستی بلاگ catch رو اجرا کن

persian-boy
پنج شنبه 05 مرداد 1391, 14:45 عصر
ممنون از دوستان
پس که اینطور

مشکل من این بود که catch رو با cache اشتباه گرفتم . به خاطر همین برام مبهم بود که کاملا متوجه شدم با توضیحات شما دوستان .

اسم اینکار چیه ؟ آیا اسمی داره ؟ مثلا من میخوام در موردش تحقیق کنم و بیشتر بدونم باید دنبال چه اسمی بگردم ؟

persian-boy
پنج شنبه 05 مرداد 1391, 20:04 عصر
یک مورد دیگه که سوال برام پیش اومد . اینکه چرا از این استفاده میکنیم ؟ طبق توضیح دوستمون این میگه خطوط داخل try رو انجام بده ، اگه نشد بلاک catch رو اجرا کن . این کار رو شرط if هم انجام . مزیت این نسبت به if چیه ؟

persian-boy
جمعه 06 مرداد 1391, 16:46 عصر
همچنان منتظر راهنمایی های دوستان

eshpilen
شنبه 07 مرداد 1391, 22:03 عصر
یک مورد دیگه که سوال برام پیش اومد . اینکه چرا از این استفاده میکنیم ؟ طبق توضیح دوستمون این میگه خطوط داخل try رو انجام بده ، اگه نشد بلاک catch رو اجرا کن . این کار رو شرط if هم انجام . مزیت این نسبت به if چیه ؟
انعطاف Exception ها بیشتره و بعضی جاها راه بهتریه.
روشهای کنترل خطا انواع دیگری هم دارن که معرف همگان هست و خیلی جاها همون روشها کفایت میکنن.
بعد میشه گفت PHP امکان استفاده از Exception ها رو هم گذاشته تا کسانی که این روش رو ترجیح میدن یا برای برنامه هایی که مناسبتره استفاده بشه. وگرنه ما میبینیم که در توابع خود PHP از روشهای مختلف دیگری استفاده شده.

این دو مقالهء مرتبط درمورد پرسش شما:

http://en.wikipedia.org/wiki/Try_catch
http://en.wikipedia.org/wiki/Semipredicate_problem

بخشهایی از اونا رو براتون میذارم:


In systems without exceptions, routines would need to return some special error code (http://en.wikipedia.org/wiki/Error_code). However, this is sometimes complicated by the semipredicate problem (http://en.wikipedia.org/wiki/Semipredicate_problem), in which users of the routine need to write extra code to distinguish normal return values from erroneous ones.


ترجمه «در سیستمهای بدون Exception، روتین ها نیاز دارند یک کد خطای ویژه را برگردانند. اما این بعضی وقتها بخاطر Semipredicate problem پیچیده میشود، که در آن کاربران یک روتین نیاز دارند تا کد اضافه ای را برای تشخیص مقدارهای برگشتی نرمال از مقدارهای برگشتی خطا بنویسند.»


In computer programming (http://en.wikipedia.org/wiki/Computer_programming), a semipredicate problem occurs when a subroutine (http://en.wikipedia.org/wiki/Subroutine) intended to return a useful value can fail, but the signalling of failure uses an otherwise valid return value.[1] (http://en.wikipedia.org/wiki/Semipredicate_problem#cite_note-0) The problem is that the caller of the subroutine cannot tell what the result means in this case.


ترجمه: «در برنامه نویسی رایانه، یک semipredicate problem وقتی رخ میدهد که یک زیرروتین که درنظر است تا یک مقدار قابل استفاده را برگرداند دچار شکست میشود، اما اعلان شکست یک مقدار برگشتی ای را استفاده میکند که در غیر این صورت مقدار مجازی میبود. مسئله اینست که فراخوانندهء زیرروتین در این حالت نمیتواند بفهمد که نتیجه به چه معنا است.»

حالا برای حل این مسئلهء semipredicate problem روشهای مختلفی هست که یکی از اونا استفاده از سیستم Exception هاست.

ضمنا مشکل روشهای کنترل خطای دیگر فقط همین یک semipredicate problem نیست و بعضا و بسته به کاربرد و محیط و جزییات عملیات و کد ممکنه بعضی مشکلات و محدودیت های دیگری هم وجود داشته باشه.

مثلا شما تصور کن ما چندتا فراخوانی از تابع/متد مورد نظر رو در قطعه ای از کد داریم. اگر از روشهایی مثل مقدار برگشتی تابع بخوایم برای چک کردن خطا استفاده کنیم، نیاز داریم تا برای هر فراخوانی تابع یک کد چک کردن مقدار برگشتی برای خطا هم بنویسیم، ولی با Exception ها ما میتونیم صرفا هرچندتا فراخوانی که در یک قطعه کد یا بخشی از الگوریتم هست رو بصورت ساده انجام بدیم و تمام اون کدها نهایتا در یک بلاک try و catch کلی باشن و کدی که خطا رو چک میکنه و عمل مقتضی رو انجام میده یکی شده باشه و بصورت متمرکز و کلی تر در اومده باشه.

کلا زیاد نگرانش نباش. این تنها روش موجود نیست و ضرورتی نداره در همه جا و برای همه کاری استفاده بشه. ولی میشه گفت درکل یکی از بهترین و منعطف ترین روشهای موجوده. البته بنظرم بیشتر برای حالتهای کلی و یا در کدهایی که میخوان در کدهای دیگری استفاده و ترکیب بشن اینطوره. فرضا ممکنه ما یه تابعی مینویسیم که میخواد بعدها در کدهای دیگری استفاده بشه. فرض کن الان تابع ما مقادیر منفی برگشت نمیده و بنابراین مقدارهای منفی رو بعنوان کدهای خطا درنظر میگیریم. حالا اگر بعدا تابع ما محدودهء اعداد منفی رو هم معنا دار دونست و بعنوان مقادیر مجاز برگشت داد، نمیشه در کدهای قدیمی ازش استفاده کرد و مشخصات اینترفیس تابع ما بهم میخوره. ولی با Exception ها چنین مشکلی نداریم و میتونیم بعدها هر نوع و هر تعداد Exception دیگری رو هم که میخوایم بهش اضافه کنیم.

احتمالا یک مشکل دیگر مقدارهای برگشتی بعنوان کد خطا اینه که هر تابعی بسته به کاربرد و محدودهء مقادیر مجاز و غیرمجاز خودش ممکنه از مقدارهای برگشتی با نوع و مقدار متفاوتی بعنوان اعلان خطا استفاده کنه. بعضیا هم که ممکنه دچار مشکل semipredicate problem باشن (یعنی بازهء مقادیر برگشتی اونا جای خالی کافی برای کدهای خطا نداره) و از مکانیزمهای اضافی دیگری که هست و در مقالات معرفی شده آمده استفاده کنن. بنابراین ما یک مکانیزم واحد و سازگار رو نداریم و هر تابعی یک جور روش اعلان خطا و یک مقادیر خطای متفاوتی داره و این کار یادگیری و کدنویسی رو هم مشکل تر میکنه.

ولی البته اینم باید بگم که فکر میکنم خیلی جاها، یعنی بنظرم بیشتر درمورد کارها و توابع ساده و سرراست، روش Exception ضرورتی نداره و همون روشهای ساده ای مثل مقدار برگشتی کوتاهتر و خواناتر و بهینه تر هستن.
یعنی فکر نمیکنم اصراری باشه همه جا از یک روش استفاده کنیم، و کم و بیش میتونیم از روشهای مختلف و ترکیبی از تمام روشها استفاده کنیم. چیزی که بنظر میرسه در عمل هم در زبانهای برنامه نویسی و کتابخانه ها و برنامه ها دیده میشه.

مثلا میتونیم یکسری مواردی رو که نیاز دارن کلی تر و منعطف تر باشن با روش Exception پیاده سازی کنیم، و یکسری توابع و عملیات ساده تر رو، یا درواقع اونایی رو که اینترفیس خطای اونها بقدر کافی مشابه و ساده هست، با روشهای ساده تر پیاده کنیم.

کلیتش بنظر بنده در برنامه نویسی در اینطور موارد و جزییات نباید خیلی سفت و سخت و مطلق بود. چون در عمل اینطور نیست و روشها و نظرات زیاد و متفاوتی وجود دارن که هر روز هم میتونن تغییر کنن. در هرجا بسته به شرایط و اولویت ها از اون روشی که بنظرتون راحت تر و مفیدتره استفاده کنید، ولی ساختار و مزایا و معایب هر روشی رو بدونید و مد نظرتون باشه تا بتونید به موقع ازشون استفاده کنید.

Variable
یک شنبه 08 مرداد 1391, 00:20 صبح
یک مورد دیگه که سوال برام پیش اومد . اینکه چرا از این استفاده میکنیم ؟ طبق توضیح دوستمون این میگه خطوط داخل try رو انجام بده ، اگه نشد بلاک catch رو اجرا کن . این کار رو شرط if هم انجام . مزیت این نسبت به if چیه ؟

من فکر میکنم ساده ترین دلیلش این باشه (شاید هم اشتباه میکنم) که :
مگه شماچند نوع خطا رو میتونی از قبل پیش بینی کنی. که بگی خب اگه فولان خطا رخ داد. این کار و اگه فولان خطا. اون کار و اگه ....
خب با این روش میتونی انواع خطاهارو کنترل کنی. . بعد خطایی که رخ میده رو با پیغامی که درونش هست . میتونی تصمیم بگیری یا به کاربر نشون بدی

eshpilen
یک شنبه 08 مرداد 1391, 08:07 صبح
من فکر میکنم ساده ترین دلیلش این باشه (شاید هم اشتباه میکنم) که :
مگه شماچند نوع خطا رو میتونی از قبل پیش بینی کنی. که بگی خب اگه فولان خطا رخ داد. این کار و اگه فولان خطا. اون کار و اگه ....
خب با این روش میتونی انواع خطاهارو کنترل کنی. . بعد خطایی که رخ میده رو با پیغامی که درونش هست . میتونی تصمیم بگیری یا به کاربر نشون بدی
در روشهای دیگر هم لزوما نیازی نیست که همه خطاها رو از قبل بدونیم.
بطور مثال یک تابعی که مقادیر نرمالی که برگشت میده مثبت یا صفر هست میتونه از مقادیر منفی برای کدهای خطا استفاده کنه، و یک تابع یا آرایه دیگه میتونه این مقدارهای خطا رو به پیامهای خطای مربوطه نگاشت کنه.
یا مثلا در بعضی جاها از یک متغییر گلوبال مثل errno (http://en.wikipedia.org/wiki/Error_code) برای بدست آوردن کدهای خطا استفاده میکنن و خود تابع میتونه یک مقدار واحد رو برای تمام خطاها برگشت بده.
همچنین روشهای دیگری هست مثل Multivalued return (یعنی تابع بوسیلهء امکانات سینتاکس زبان یا حتی احتمالا ترفندهای خاصی چند مقدار شامل کدخطای احتمالی رو برگردونه یا بهرصورت کدهای خطا رو از مقدارهای برگشتی قابل تفکیک کنه).
یا مثلا استفاده از پارامترهای out در زبانهایی که از pass by reference (http://en.wikipedia.org/wiki/Pass_by_reference) پشتیبانی میکنن.
خلاصه راههای متعددی داره که حتما حداقل بعضیاش رو دیدید. در خود PHP از چندتا از این روشها استفاده میشه.

تمام این مواردی که گفتم در لینک هایی که گذاشتم بهشون اشاره شده.
و به مشکلات و محدودیت هایی هم که این روشها ممکنه داشته باشن اشاره کردم.
بهرحال همونطور که گفتم Exception ها برای موارد کلی و سناریوهای پیچیده تر مناسبتر بنظر میان و باعث یکدست تر شدن و منعطف تر شدن ساختار کدنویسی میشن.
بنظرم Exception ها کم و بیش موجب جدا شدن مکانیزمهای خطا از اینترفیس هم میشن که فکر میکنم به برقراری اصول مهندسی نرم افزار کم و بیش کمک میکنه. یعنی مثلا اگر بخوایم مقادیر یا بازه مقادیر برگشتی تابعی رو تغییر بدیم، مشکلات کمتری خواهیم داشت و کدهای قدیمی کمتری دچار ناسازگاری میشن. البته به این مورد هم قبلا اشاره کردم!

eshpilen
یک شنبه 08 مرداد 1391, 08:35 صبح
الان این مقاله رو دیدم که توضیحات عالی ای داده: http://en.wikipedia.org/wiki/Error_code
حیفم اومد ترجمه نکنم.
ترجمش رو میذارم و متن اصلیش رو از خودش میتونید ببینید.

درمورد کدهای خطا میگه: «آنها نوعا برای مشخص کردن سخت افزار یا نرم افزار خطادار یا ورودی کاربری نادرست در زبانهای برنامه نویسی ای که Exception handling ندارند استفاده میشوند، هرچند آنها بعضی اوقات همچنین همراه با Exception handling استفاده میشوند.»

این بخش خیلی خوب دربارهء مزایای کلی Exception handling توضیح داده: «همچنان که زبانهای برنامه نویسی شیء گرای مدرن آنها را با Exception ها جایگزین میکنند، کدهای خطا به آرامی درحال محو شدن از محیطهای برنامه نویسی هستند. Exception ها این مزیت را دارند که با بلاک های صریح کد هندل میشوند که از بقیهء کدها جدا هستند. درحالیکه در متدولوژی هایی که کدهای خطا و مقدارهای برگشتی را برای نشان دادن شکست استفاده میکنند آن اغلب یک رویهء ضعیف تلقی میشود، اما برنامه نویسان اغلب از چک کردن مقدارهای برگشتی برای شرایط خطا غفلت میکنند. آن غفلت میتواند به اثرات نامطلوبی منجر شود، چراکه شرایط خطای نادیده گرفته شده اغلب در مراحل بعدی برنامه موجب مشکلات بزرگتری میشوند. Exception ها به شکلی پیاده سازی شده اند که کد هندل کنندهء خطا را از بقیهء کد جدا کنند. جداسازی کد هندل کنندهء خطا از منطق عادی، برنامه ها را برای نوشتن و فهمیدن ساده تر میکند، چراکه بلاک کد هندل کنندهء خطا میتواند خطاها را برای هر تعدادی از فراخوانی های تابع سرویس دهی کند. Exception handling همچنین کد را خواناتر از پیاده سازیهای با کدهای خطا میکند، چراکه Exception handling جریان کد را با چک کردن های مکرر برای شرایط خطا گسیخته نمیکند.»

توضیحات روشنی داده، ولی بازم بنظرم در موارد ساده و محدود، Exception handling اینقدر مزیت نداره و شاید کار اضافه بنظر بیاد. بنظرم کدش بیشتر میشه.
البته باید توجه داشت که ساختار بلاک های try-catch رو باید بصورت هوشمندانه طراحی کرد تا کد تاحد ممکن کوتاه و خوانا و کدهای مربوط به شرایط خطا از کدهای منطق عادی برنامه جدا بشن. وگرنه اگر بخوایم هر چک کردن خطا با if رو صرفا با یک بلاک try-catch جایگزین کنیم که مسخره میشه و فقط کار خودمون رو زیاد کردیم.

Sajjad.Aghapour
یک شنبه 08 مرداد 1391, 13:48 عصر
شما در طراحی ماژول ها و کامپوننت ها و یا وقتی دارید از تکنولوژی Object Oriented استفاده می کنید از اهمیت این مکانیزم برای کنترل خطا در برنامه نویسی پی خواهید برد. خود PHP برای کنترل این استثنائات از متغیرها استفاده میکنه. برای مثال اگر آپلود فایلی با خطا مواجه شد مقدار false برای شما برگردانده می شود. یا استفاده از mysql_connect و بسیاری از متدهای دیگر. اما در برنامه نویسی و توسعه کتابخانه ها دیگه از این مکانیزم استفاده نمیشه.

برای مثال شرایطی رو در نظر بگیرید که یک مقدار رو میخواهید به یک فایل متنی روی سرور Append کنید. خوب اگه نوشتن روی این فایل با خطا مواجه شد چه اتفاقی افتاده؟ فایل وجود نداشت؟ وجو داشت ولی شما Permission نداشتید؟ سرور در دسترس نبود؟ و بسیاری از سوالات دیگه که ممکن هست برای شما پیش بیاد. به نظر شما با برگشت یک مقدار Boolean کار درسته؟ شاید بتونید کدهای خطا رو برگردونید و براساس اونها پیغام مناسب رو نمایش بدید اما صد در صد مطمئن باشد که بعد از یک مدت این کار برای شما دردسر خواهد شد.

با استفاده از Exception Handling شما قادر خواهید بود آنچه که نیاز هست برای دانستن از یک خطا به خصوص Trace اون خطا دسترسی داشته باشید. صراحتا نوع خطا رو مشخص کنید: IOException, InvalidArgumentException, AccessViolationException و انواع دیگری که ممکنه قبلا تعریف شده باشه یا توسط خودتون با Extend کردن کلاس Exception تعریف شده باشه.

موفق باشید/

eshpilen
یک شنبه 08 مرداد 1391, 21:27 عصر
البته یکی از مزیت های Exception که در متونی که قبلا آوردم هم بهش اشاره شده، اینه که اگر یک Exception هندل نشه برنامه متوقف شده و اجرا در همونجا خاتمه پیدا میکنه.
ظاهرا علما به این نتیجه رسیدن که این روش بهتره.
با مقدارهای برگشتی و روشهای دیگه ممکنه اینطور نباشه و برنامه با وضعیت اشتباه به اجرای خودش ادامه بده و مشکلات بیشتری به بار بیاد.